In part 1, I tried to explain the various “Editions” of Java, and mentioned that Java Enterprise Edition is very much a misnomer. In this post we will take a look at why this is, and what Java EE is actually all about.
It’s all about the Specs
If we want to get really technical, Java EE is not a runtime environment, nor is it a single technology. If you want to get really technical, Java EE is a collection of specification documents which define how several different enterprise technologies should work in Java.
What are “Enterprise technologies”?
This is where things get dicey. There’s no formal definition of what is or isn’t an Enterprise technology, so the term means different things to different people. The best way I can describe them is that enterprise technologies help solve particular kinds of problems that large corporations are often (but not always) worried about. The important thing to remember is that you can still write a big, complicated application that doesn’t use any enterprise technologies. They are there when you need them, but you don’t need to use them unless you know they will be useful.
Here a few examples of the problems solved by Java EE (though this list is far from all encompassing):
- Java EE includes a specification for a messaging system which can guarantee delivery of data, which is often important in applications in which data loss is unacceptable.
- There is a specification for how to write Java code that handles HTTP requests and responses, the importance of which is fairly obvious.
- There is a specification that allows you to map a Java object to a database table, making it possible to save data without having to write any messy, error prone SQL.
- There’s a spec that defines different kinds of Java objects with different scopes - some are created once and last for the life of the application, while others are created fresh every time they’re called upon. This can result in nice performance benefits and a logical organization of your code.
The list goes on from there. Again, most of this stuff is intended to establish certainties for things that companies often like (or need) to be certain about.
Spec vs Implementation
So we have these specifications. Where do we go from there? What happens is that anyone is free to write a piece of software which implements one or more of the specs. In reality, most of the implementations out there are written by Oracle and other large entities, such as Red Hat, IBM and the Apache Foundation.
The Reference Implementation
Traditionally, there is always one implementation of each technology which is considered the “reference implementation”, which all others should use as a model (or even use its source code as their base). These days reference implementations aren’t talked about as much as they used to, mostly because the various solutions are all very effective and usable.
Bits and Pieces
Most of the implementations can be used standalone, which allows you to pick and choose which technologies to include in your project. The other option is to use a Java EE Application Server (EAA). There are several EAA’s out there; they’re basically web servers which support all of the Java EE technologies. When Oracle calls Java EE a “runtime environment”, they’re referring to these Application Servers. In reality, however, there’s nothing special about them.
Gotchas
Java EE specs are mostly concerned with establishing a baseline of features that an implementation must support at minimum. To that end, they each provide an API, with class and package names that must be used and supported. This provides a level of commonality and interoperability. If you write code against the standard API’s only, you swap one implementation out for another without having to change a lick of code.
On the flip side, the specs don’t stop your from adding anything extra to an implementation. The only rule in this regard is that you must use different class and package names. Naturally, every single implementation adds something extra, in an effort to entice you to use their product to the exclusion of the rest. If you choose to use these features, you won’t be able to change implementations without doing some work.
At this point you might be asking yourself why you would ever switch from one solution to another. There are any number of reasons why it can happen, and I can say from experience that sooner or later it will happen to you. Just keep that in mind.
More than one Way
You must also remember that Java EE is only one effort at solving enterprise technology challenges. There are other libraries and frameworks that are also trying to solve them. The most notable of these alternatives is the Spring Framework. When making a choice on what technologies to use, make sure you do your homework and find the one that is the best fit for your team.
Conclusion
Now that we’ve taken the general tour of Java EE, future articles will go into detail about some of its specific components. These entries will remain fairly technical, but will also be a bit more opinionated than this overview. Fair warning.