The thin line between Java SE and Java EE

I am the guy who writes java controllers (mvc), who does tests with junit, who writes jdbc, who uses maven ...

basically, how do I know when is this Java EE and when is not? I don't write servlets or jsps (which are part of Java EE) but I do use API and so ...

What am I? Java EE programmer? Java SE programmer? If you were Spring/Hibernate developer, what you are? Java EE or Java SE?

Maybe t开发者_StackOverflow中文版his is stupid question (if so then I am sorry), but what's the "thin line" between Java SE and Java EE?

More importantly, does it matter?

"What's in a name? That which we call a rose

By any other name would smell as sweet."

The only purpose for having these labels is as a shortcut for bundling technologies together. I share your view that these are exceptionally handwavy terms, and consequently no-one is going to use them for anything of consequence.

Sure, companies might advertise for a "J2EE developer". But they'll always mention in the description/interview that they mean e.g. JBoss and JPA, for instance, rather than simply saying "are you J2EE" and assuming you both know exactly what that means.

And outside of that specific example, I very rarely come across the terms used (because they're not very useful). Asking if you have experience with Java is useful, at a more precise level asking if you have experience with Tomcat or Hibernate is useful, but asking if someone has experience with J2EE is unlikely to yield a usable answer.

Is there some specific circumstance that's prompted you to ask this question?

JDBC is part of the core Java SE spec.

It goes without saying that Java EE is built on top of Java SE. If you're Java EE, you're automatically Java SE as well.

Servlets and JSPs are part of Java EE, but some people don't consider you to be fully Java EE unless you're using EJBs and app server services like connection pooling, naming, queuing, etc.

Spring was a reaction against EJB 2.0 and its complexity. It's built on top of Java SE, usually deploys on Java EE app servers, and provides a lot of Java EE functionality (e.g., persistence, lifecycle, etc.) without resorting to the EJB machinery. It uses servlets, JSPs, persistence, naming, queuing, and other Java EE services to do its work. Spring is not a Java EE spec; it's the brainchild of Rod Johnson. It's now owned by VMWare.

J2EE is a collection of APIs and Specifications for Enterprise Development, if you're not using any of those API's then, from my point of view you're a J2SE Developer, even when using Spring.

Of course, anyone who does J2EE development also has to do J2SE development by default, since all those J2EE API's are based and built over the Java language platform.

Java EE is a huge API. You're using mainly the Java EE web profile. So, I'd say, you're a "Java EE web application developer". For the specific skills, just use the room you have in your CV and/or interviews.

It is java EE when the code knows it is in a EE context. Classes or interfaces only presnt in a EE contxt and which doesn't make sense in a SE application.

For resumes just list "Java" with the technologies you've used.