Question

I’m just implementing a JavaEE assignment I was given on an interview.

I have some prior experience with EJB, but nothing related to JMS and MDBs. So here’s what I find through the numerous examples:

• application servers bind their topics and queues to different JNDI names – for example topic/queue, jms
• the activationConfig property is required on JBoss, while in the Sun tutorial it is not.
• after starting my application, jboss warns me that my topic isn’t bound (it isn’t actually – I haven’t bound it, but I expect it to be bound automatically – in fact, in an example for JBoss 4.0 automatic binding does seem to happen). A suggested solution is to map it in some jboss files or even use jboss-specific annotations.

This might be just JBoss, but since it is certified to implement to spec, it appears the spec doesn’t specify these these things. And there all the alleged portability vanishes.

So I wonder – how come it is claimed that JavaEE is portable and you can take an ear and deploy it on another application server and it magically runs, if such extremely basic things don’t appear to be portable at all.

P.S. sorry for the rant, but I’m assume I might be doing/getting something wrong, so state your opinions.

Answer 1

Java EE, like (almost?) any standard, is something that implementers strive to advertise adherence to but desperately don’t want to adhere to.

Consider this question: how does Red hat make money? By giving things away or by selling them? If the code you wrote could be easily transferred to another Java EE application server, this would interfere with them making money from you. The solution to this is the venerable “embrace and extend” technique that has been attributed to Microsoft but in reality has been the tool of choice for commercial software vendors since the first standard was published.

If you stick strictly to the Java EE APIs in your code then JBoss (or Geronimo (or JonAS (or …))) will run it as well as any other compliant application server with the only changes being required in the server-specific deployment descriptors. This is the embrace stage.

Each server — the commercial ones (like JBoss) in particular! — also tends to add extra stuff to the API to “make things easier”. (To be fair these often do make things easier.) Developers — especially those not intimately familiar with the standard APIs — frequently fall into the trap of relying on these extra APIs without wrapping them in any way, thus allowing these extensions to inundate their code to the point that they’re difficult to remove should you wish to change platforms. This is the extend stage.

Name a standard from any point in software history and you’ll find people embracing and extending (to the point that when people talk about “deadly embrace” I have to forcibly move my thoughts away from vendor lock-in problems to the proper terminology). You’ll also find end-users (developer or otherwise) falling for it. Java EE is no different than any other technology in this regard.

Then you factor in just how badly-worded most specifications are and …