JavaEE: programming model or application server interface?

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.

Comments (5)

  1. mgroeneveld - Reply

    December 7, 2006 at 9:17 am

    I thought that the reason J2EE is used is because of all these programming models. So if you don't use it for that, what kind of architecture can you create with just the APIs? They leave so much freedom that you need to come up with a lot of programming-models yourself.

  2. Bart Guijt - Reply

    December 7, 2006 at 11:41 am

    Great post, Vincent! I wholeheartly agree about those polluted JavaEE programming model fallacies. Especially concerning the Servlet API 'stack', on top of which all kinds of specs are developed: JSP, JSF, JSTL, EL, and whatnot. It’s a complete mess.

  3. Vincent Partington - Reply

    December 7, 2006 at 12:16 pm

    mgroeneveld: of course you need programming models. My point is that Sun has done a lousy job coming up with them. Witness JSF, EJB, JAX-RPC, etc. Instead of trying over and over and thereby messing up the JavaEE spec, they should just leave the programming models to the free software community.

    Regards, Vincent.

  4. Chand - Reply

    December 26, 2006 at 11:03 am

    Nice post !!!

    Nicer replies....

    P stands for Points

    (P1) What worked stably in the market...

    Yes : JMS , JTS , servlet worked in the market.

    But half truth....

    (P1.1)Servlet worked "managed" by Struts framework.

    Some one writes code only in struts soon gets lost in the mess of code.

    (P1.2) JMS is basic asyn modal. Service Bus was required to abtract different things.... Need to standardize like JMS. No one use JMS raw. Sounds very technical in code.

    (p1.3) JTA : Made 2 phase work. But Nested transaction etc. Never picked up because of valid scenorios taught in school. No one code in JTA.

    Able room for Transaction Manager "Interpreter" language to be used to make it useful.

    Check OBfiz Minilang. Ofbiz is apache project.

    ---------------

    (P2) Programming Model.

    Sun says everything is resource. Stored info of concreate resource in JNDI. IN ur calling code , create instance of the Factory based what is present in JNDI tree. and create objects.

    Did try to standardise the calling pattern.

    Should had DONE more to standardize the pattern. Give it fancy name.

    Spring Next version need to use "Template" pattern to depict new way or the same old way for different but identical programming model.

    Spring could give "Templates for different programmng model" in the next release.

    (P3 ) JSP, JSF, JSTL, El mess : Answer look sun has its hands tied on..... many people use something only if it standard. People may not want democracy.

    Somewhere I read article " Falacy of multiple framework". stating Most web frameworks are identical. Struts is accomative and allows merge ; as with Struts 2.0 . It might land up being the framework giving minimum benefits of all.

    So sun or apache did try to standardize a bit. Helps.... not a bad idea.

    (P4) New Point. : Where is Web 2.0 framework.....

    Sun does nothing. Nothing happens.

    (P5) Apache becoming SUN like standards. Apache is quicker due to less restrictions.

    Feel free to reply to chandturakhia74@hotmail.com

    Chand

  5. Xebia Blog - Reply

    March 9, 2007 at 4:13 pm

    [...] Home grown frameworks. Because Java EE, and especially the older version, offered such a poor programming model, a lot of home grown frameworks have been written. Although these form a central part of the application, not all of them are tested for performance. [...]

Add a Comment