Java has been around for more than 10 years now and has accumulated a lot of unneeded stuff:
- Deprecated methods, classes and packages that are never removed,
- Packages hardly anybody ever uses (when was the last time you used javax.sound.midi?), and
- Language features that have turned out differently then we imagined:
- Packages were meant as namespaces to separate identically named classes. However, because package names are usually quite long and the average Java class import tens of other classes and we then collapse the import list in our IDE, we tend to get annoyed when an identically named class exists in multiple packages.
- The distinction between java and javax was meant to convey that javax packages were extensions to the standard class library. However, since JavaSE now contains lots of javax packages that is no longer the case.
You could call that stuff Java's
vestigial structures. They served a purpose at some point during Java's evolution but have since lost their function. Unfortunately, backwards compatibility prevents us from haphazardly removing those features.
Anyway, the same has happened to the JavaEE specification.
After nearly 10 years of enterprise Java specifications (starting with the Servlet API back in '97), we can see that the following API's have not really proven out to be all we thought they would be:
- EJB 1.x and 2.0 - replaced by EJB 3.0.
- JDO - obsoleted by JPA before it was ever really used.
- JAAS - meant for client applications but used in JavaEE application servers in convoluted ways.
- JAX-RPC - replaced by JAX-WS only one version later!
- JSF - still fresh now, but I have a feeling it's not going to make it when compared to the myriad of web frameworks already out there.
- JavaBeans Activation Framework - needed for JavaMail and JAX-RPC but kinda crappy.
And with some more thinking the list could be extended somewhat more. Anyway, I'm not writing this to knock all those API's; there's probably enough blogs doing that already. ;-)
No, I think the problem is deeper than that.
The problem is that JavaEE tries to be a programming model when what we really need is an interface to the application server and its environment.
Let me explain. Compare the Servlet specification to the JSP specification. You can't go without the Servlet spec because it defines the contract between your application and the application server. If you write your application against the Servlet API, you can run it in any application server. So the Servlet API gives us the much coveted feature of portability.
Superficially, the same thing goes for JSPs. But that does not really fly; you could simply include a Servlet to interpret your JSPs (I know,
I wrote one) and that would provide you with the same functionality, even more portability across application servers (no dependency on specific JSP compiler features), but also more flexibility to change that Servlet.
The JSP spec is really only there to provide a programming model for the JavaEE developer, we could do without the JSP spec if all we needed is portability across JavaEE application servers.
Other API's that support this JavaEE-as-a-programming-model notion are:
- EJB
- JDO
- JPA
- JSF
- JAX-RPC, JAX-WS
- JAXR, JAXB, JAXM
- SAX, DOM, JAXP
- JavaMail
- JavaBeans Action Framework
While the following API's are really interfaces between your application and the application server and its environment (database server, messaging infrastructure, etc.), supporting the JavaEE-as-an-appserver-interface notion:
- JMS
- JDBC
- JTS
- and of course, the Servlet API
It's no coincidence that light weight JavaEE frameworks like the Spring framework make use of the latter type of API's while replacing the first type! Also, you may notice that the list of interface API's is a lot shorter than the first one, and also does not include any API's that have been obsoleted (JAX-RPC was obsoleted after just one J2EE version!).
It would be very beneficial to the JavaEE stack if the next version of JavaEE focused on what it really needs to do and not try and emulate the .NET environment by adding stuff like JSF or JPA. It would give us a smaller, more stable, JavaEE and not divert the application server vendors' focus from what they need to do: implement really fast Servlet containers and the like. Most people are already using the light weight alternatives to the JavaEE-as-a-programming-model API's anyway.
In the meantime, the programming-model API's can be left to the free software community which has done a pretty good job with them for the last 5 years and has proven to be able to adapt faster to changing requirements than the JavaEE specification has been able to.
