by Steven J. Owens (unless otherwise attributed)
I seem to hear a lot more about J2EE than about J2SE. Maybe you do too, and maybe that confuses you. It's not your fault.
Note: For the longest time it was J2EE. These days everybody's on JDK 1.6 or 1.7 or is that Java 7 or what the heck... so it's JEE or Java EE or whatever people come up with. The confusion continues...
J2SE stands for "Java2, Standard Edition" and just basically means "the java stuff". It's the general term for the all the stuff you get when you install the JDK (java developer's kit), whatever we're calling it today (JDK, Java SDK, J2SE, Java 2, Java 1.6, Java 6, etc). This is the JVM (the program you run when you type "java"), the java core APIs, the compiler and various other bits and pieces of the developer's kit (like the jar tool). Strictly speaking, J2SE is "the platform", so the various developer kit tools aren't part of it. J2SE is everything that every J2SE program can count on having available when it runs.
J2EE, on the other hand, is everything that every J2EE program can count on having available when it runs. It's J2SE plus. Although people sometimes talk about J2EE and J2SE as if they're opposites, or contrasts, or something, J2EE is really built on top of J2SE. It's a superset of J2SE. It's J2SE with a bunch of extra pieces added in to make it easier to develop Enterprise-oriented applications - the extra E in J2EE.
When I say "pieces", I really mean "specifications", which java programmers also call APIs. Strictly speaking, the API is the objects and method calls for an implementation of the spec, but programmers use "API" as shorthand, because it's shorter than specification - two whole syllables! And it's a TLA (three letter acronym), too! Sometimes we call 'em "specs" but most programmers think that's going too far in the quest to avoid superfluous syllables.
There are open-source reference implementations of these specs, but there are also a lot of closed-source, commercial implementations. There're a good couple dozen specifications that make up J2EE. Okay, I'm exaggerating; I just went back and counted and there are only 23 at this moment. I could spend pages just trying to summarize them. Here's the link to the sun web page that lists them:
http://java.sun.com/j2ee/1.4/docs/#specs
And here's the J2EE Tutorial, if you have the time:
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/
The J2EE picture is further complicated because all of the various vendors (and many other open source projects) are trying to come up with value-added add-ons to J2EE. But you can carve this list of specs up into some that are fairly specific and narrow, some that are well-defined and well-documented problems, some that are both specific and well-documented, and some that seldom get talked about but get used a lot, and some that seem to get more talk than actual use. I'm going to take a moment and try to carve up that list a little, off the top of my head.
These are the specs that most people think of when you say "J2EE".
They may also bother to think of these, especially if their particular bailiwick makes heavy use of them:
But, more likely they'll lump the above in with these, which they sorta take for granted:
Then there are all of these, some of which are subsidiary to other specs (for example, the EJB-to-CORBA spec) and others of which are oriented at just making life easier in Enterprise Application Land (like the J2EE deployment and management stuff) and still others that are part of the plumbing and special cases that you hopefully never have to see unless you're developing J2EE tools and components (like the J2EE Connector spec):
JNDI, for example, Java Naming and Directory Interface, is basically a hierarchical name-based lookup server that you can publish objects into, then look them up by name (kinda line DNS, only you're looking up java objects instead of looking up IP addresses). In some cases JNDI is the API you use to get at a full-blown LDAP server that is also being hit by a bunch of other software in the rest of the enterprise. One common organizational use for LDAP is to keep all the usernames and passwords in one spot. If you're going to plug your application into the same LDAP server, then you need to know at least a little JNDI and how to use JNDI from other parts of J2EE.
But, unless you're going to build stuff to let other applications interact with your enterprise app via JNDI, or use your JNDI server in new and creative ways, or implement your own JNDI server or JNDI components, you mostly don't need to know about it (except when you need to know just a tiny, tiny bit about JNDI when you configure your JDBC database pooling).
JDBC, Java Data Base Connectivity, is all about how your code interacts with the whatever database software you're using. Not the SQL bits, so much as all the scaffolding surrounding the SQL bits. How you get a connection to the database, how you send a query to the database, how you get the results of that query. There's a lot to say about JDBC and related topics, but it's covered very well in various books and is generally a really, really well-explored area, so go read that stuff to learn about JDBC.
The two highest-profile specs seem to be Servlets and EJB. But EJB seems to be talked about a lot more than it's actually done. There seems to be a large body of web applications that are written using a smallish subset of J2EE, mainly JSP/Servlets/JDBC. That's what I'm going to focus on here, and since there's a ton of documentation out there on JDBC, I'm not going to focus on that.