One of the biggest hurdles in getting a procedural developer to even try an object-oriented language is to break a bunch of misconceptions. Perhaps the largest one has to do with language syntax. When a procedural person sees something that looks like a structure with code in it, they instantly think that each structure “carries” its own copy of the code around with it — which is clearly inefficient.
Once you explain that, no, there is only one place the code exists, and that the notation is defining scope, not structure, it becomes obvious how the compiler is accomplishing its magic. In fact, it’s quite trivial, impressive, and elegant.
In some ways, I wish someone had explained to me long ago what was up with selecting a Java environment, because Java loves to rename itself, bust its environments into pieces, invent new terminology for old things, and in general make a whole confusing mess to anyone who didn’t come along for the ride since day one. I’m about to explain to non-Java newbies just what J2EE / Java EE is in a simple matter you could explain to your grandmother. Assuming, of course, your grandmother wrote code.
If you hop over to the java site and poke around, you’ll see on the right hand side three things: the JRE, the SDK, and something called EE.
Let’s recap. JRE is the runtime environment, it’s for when you want to run programs, but have no need to compile them. The JDK (Java Development Kit) got renamed to the SDK (Software Development Kit) when more than just the Java compiler got packaged with it. Java, Java 2, and Java 5 are all the result of marketing names, having some relationship to the actual version number scheme: v1.2 is Java 2, but so is v1.3, v1.4. Java 5 is v1.5. Thanks Sun, this isn’t helping.
But what is EE, the Enterprise Edition? What does Enterprise mean? What is business logic? Why is it different than the SDK? Why isn’t it included with the JDK? What’s up with a client piece and a server piece? Why is it always seemingly a version or so behind the SDK? And, why, oh why, can’t Sun just give me one huge thing to download with everything in it?!?
To date, I’ve seen no one give clear cut answers to the above. And I’m about to. And the reason you don’t have those answers is because if you’re asking those questions, then you’ve got some serious misconceptions about what’s going on. Don’t blame yourself though, often people who want to be part of something exclusive make things seem more complicated than it really is and then disguise that fact with strange terminology. All is about to be clear.
The primary misconception is that the SDK is what you use to develop client applications, and that the EE version is what you use to develop server applications. Now anyone who’s done any socket programming will totally roll their eyes at the fact that the library has been split depending on which side initiated the connection, and they’ll do it in much the same way as someone who looks at a object oriented class does when they erroneously think code is being put in a structure.
What’s happened is that the terms client and server have been changed out from under you without warning. And, happily, the SDK is capable of doing both the client and server side of a socket connection. That’s not what EE is about.
J2EE (the Java 2 version) and Java EE 5 (the Java 5 version) are nothing more than specifications. That’s right, concepts on paper.
Let’s go back for just a second and look at some of those other fancy words.
Enterprise = a service or application should be scalable and distributable
Business Logic = code …that’s right… just code, like you’ve always written
Now you’re smart, you could write a framework for your application that would use threads, thread pools, data marshaling between systems, load balancers, and so forth. But that wouldn’t be getting the real work done, that’s just the infrastructure. Let’s face it, if you use C++ you use the Standard Template Libraries; if you do encryption, you don’t roll your own data structures and algorithms. Why should you? Domain experts with tons of field experience have carefully crafted highly optimized and well tested code for you. There’s no reason to re-invent the wheel, especially when there are people dedicated to building, maintaining, and improving the best wheels out there.
An application server is a running environment that dynamically loads classes, and provides scalable and distributable services laid out in the specification.
Java Enterprise Edition is the set of library classes that converse with an implementation of an application server that is compliant. In short, it’s programming by contract, just like everything else. Because there are several specification versions, there are several EE environments. Because EE is a large set of additional classes, you don’t need them if you are not running an application server that you need to talk to. Grabbing the Java EE will get you the SDK – all of it.
Now, here’s the catch. Because more people use the SDK than the EE, you’ll see patches and minor version updates for the SDK before you see that SDK pre-bundled with the Enterprise Edition. Nothing stops you from grabbing EE and snagging the latest patched SDK.
So, in order to run the Java enterprise environment, you need four things: 1) The compiler and tools of the SDK. 2) An application server like JBoss or the Sun Java System Application Server. 3) The Java EE application interfaces that are conforming to the application server you intend on running. 4) A clear understanding the services your application provides in addition to how to configure, start, stop, and deploy Java code that you write to it.
NetBeans, Suns interactive development environment (IDE), has a bundle that includes the IDE, the SDK, the EE, an application server (JBoss), and will install it and configure it for you.
So, to summarize: Java EE are additional classes that let you converse with an application server, which is a separate program that is compliant to a Java EE specification. The majority of people don’t use enterprise services for regular programs, and those that do need to have a class library that matches the application server they’ve elected to use — as such, it is not bloat or complexity that keeps it out of the JDK, but that putting one in can be problematic if there is a mismatch with the ‘server’ end of things.
Curious now as to what Java EE provides?
Well, it handles .JSP pages (like PHP allows scripting in web pages, instead the language used is Java). It handles Servlets (programs that respond to POST and GET requests), which is actually what a .JSP turns into if you think about it. It handles JavaBeans (classes with agreed upon properties, called interfaces, that let them be manipulated by a graphical IDE); it handles Enterprise JavaBeans that allow your code’s classes to run in a distributed manner — and, yes, it was horrible to name it so similar. It has naming services to find your code, no matter which machine it’s on. It can handle concurrency, scalability, transactions, logging, message queues, security policies, database connectivity and pooling, persistence and mapping of objects to relational databases, and so forth. …everything you could write yourself, but benefit from not having to.
