Is JaveEE Really Portable? And Is It Really Useful?
In the past hours I’ve been implementing a sample JMS+MDB+JPA application. I had to read quite a lot of tutorials, documentations and other samples, because I had no prior experience with JMS and MDB. (I had with EJBs and JPA). Note that what follows is regarding JavaEE pre-6 (apart from some general thoughts)
I had to use JBoss, with which (thankfully) I didn’t have any prior experience. Here are my morbid observations:
- the official Sun JavaEE tutorial wouldn’t run on JBoss.
- JNDI names aren’t specified so each application server choses its own. For JMS, for example, JBoss uses topic/someTopic, queue/someQueue, connectionFactory, while others use jms/someTopic, jms/someQueue, TopicConnectionFactory (or QueueConnectionFactory). So when you use @Resource(mappedName=”..”) your application automatically becomes non-portable, and application-server dependent
- JBoss requires at least the
destination property to be set as activationConfig on a @ManagedBean. But this does not appear to be a requirement by spec (and the Sun tutorial doesn’t include this)
- JBoss doesn’t automatically register topics and queues. You have to either configure their auto-creation in a jboss-specific bean descriptor, or define them in application-server-wide configuration file (again, jboss-specific)
- JPA requires a DataSource, which is defined in some application-server-wide, jboss specific way.
These are all examples that have come out after 8 hours of creating some very basic things with JavaEE. Nothing extravagant. And the application is totally non-portable. So don’t give portability as an advantage of JavaEE. Perhaps the only portable system is a Hello World.
But portability is not the worst thing. The worst thing is that the principle that at least JBoss follows is the “principle of most surprise”. Things just don’t work the way one expects them to. Perhaps I’ve been spoilt by spring, but I expect:
- to be able to configure options per-application (and not per-application-server). Preferably with some standard XSD that would allow auto-complete. Topics, Queues, DataSources, etc – all of these don’t appear to have a standard way of configuring. And JBoss lets you configure them on application-server level. When I tried to put my datasource definition in META-INF an exception was thrown that the datasource is already defined. Well, I didn’t have time to debug why it discovers it twice.
- to be able to accomplish simple tasks in simple ways – this is becoming more and more true coming from J2EE to JavaEE6, but still from time to time one has to kill flies with shotguns.
- to be given meaningful exception messages – cryptic exceptions, with bad English, including long numbers and telling simply that something failed, but rarely what, and almost never why. As a contrast I’d like to give an example from spring I was fascinated with the other day – I mistyped a bean name in my mappings (singular vs plural), and spring suggested the correct name.
- to work with something stable – NullPointerException is quite a “bug”.
- to see adequate logging – logging that a timer has timeouted or that onMessage has been called with log level of ERROR is … odd.
Now, you’d say, most of these issues are only JBoss related. I really hope WebLogic, WebSphere and Glassfish are better. But the fact that most of these things are left to vendors to decide, and they have most often taken decisions in the light of J2EE (pre-Java5), which are retained as philosophy – tons of deployment descriptors and scattered properties. Virtually random JNDI paths. “Frivolous” interpretations of the (unclear) specification.
What spring does instead? It doesn’t have a specification to implement. It has evolved naturally to the state where it meets all requirements in the most straightforward way. It has extensive and clear documentation and examples. It is working properly, following the “principle of least surprise”. It has support for everything that you get by an application server – messaging, transaction management, etc. And even more, actually – it has classes and utilities that make working with other technologies (jpa, hibernate, JMS, etc) easier and simpler. Well, of course it’s not all roses with spring, but its flaws are minor compared to these of JavaEE.
You may say here that application server provide essential production features like clustering, load-balancing, distributed transactions, which spring deployed on Tomcat (or any servlet-container) don’t have. Well, wrong. SpringSource created their tc server, which is a lightweight application server supporting many things that you need, but does not implement the JavaEE spec.
Furthermore spring has influenced and continues to influence most of the JavaEE specifications. It is at least a few steps ahead by definition.
Another argument might be that application servers are commercially supported, while tomcat + spring may be suitable for some small organizations, but not for “our big and responsible company”. Well, wrong again – SpringSource offers commercial support. If you are going to try the argument that you don’t want to get tied to a single provider, re-read the first part of this post.
As it seems, I am favouring spring and its subprojects. What I see as problems with JaveEE compared to spring are:
- JavaEE is being specified formally in big time intervals, rather than evolving steadily like spring. Thus major flaws take too much time to fix and workarounds become accepted practices. Not all cases are covered by the specifications which leads to the need of proprietary solutions. (one example – lack of delete-orphan or collection-of-elements in JPA pre-2)
- JavaEE specifications are prone to misinterpretation.
- Application server vendors actually aim at providing their custom configuration options and “quirks”, so that customers can not easily change them for another vendor. Spring doesn’t have this issues, since it is the only “vendor”. While this might sound like the same thing, it isn’t – as I mentioned above – try running the Sun tutorial on JBoss. Resources are separated and are only application-server relevant. You may find a tutorial or a solution to a problem of yours that works on WebLogic, but doesn’t on JBoss.
- Application servers are not well-written. That’s subjective opinion, but I find JBoss of low quality (see above), (and spring of very high quality). This is due to a number of reasons, including backward compatibility issues, corporate decisions, etc.
The conclusion would not be blunt. JavaEE is developing and it has its power. It definitely should not go away for at least one reason – its inadequacy has brought great frameworks like Hibernate (certainly better than entity beans) and spring (certainly better than EJB pre-3), which in turn have influenced back JavaEE (JPA and EJB3), and the process will keep going, for the better.
In the past hours I’ve been implementing a sample JMS+MDB+JPA application. I had to read quite a lot of tutorials, documentations and other samples, because I had no prior experience with JMS and MDB. (I had with EJBs and JPA). Note that what follows is regarding JavaEE pre-6 (apart from some general thoughts)
I had to use JBoss, with which (thankfully) I didn’t have any prior experience. Here are my morbid observations:
- the official Sun JavaEE tutorial wouldn’t run on JBoss.
- JNDI names aren’t specified so each application server choses its own. For JMS, for example, JBoss uses topic/someTopic, queue/someQueue, connectionFactory, while others use jms/someTopic, jms/someQueue, TopicConnectionFactory (or QueueConnectionFactory). So when you use @Resource(mappedName=”..”) your application automatically becomes non-portable, and application-server dependent
- JBoss requires at least the
destinationproperty to be set asactivationConfigon a@ManagedBean. But this does not appear to be a requirement by spec (and the Sun tutorial doesn’t include this) - JBoss doesn’t automatically register topics and queues. You have to either configure their auto-creation in a jboss-specific bean descriptor, or define them in application-server-wide configuration file (again, jboss-specific)
- JPA requires a DataSource, which is defined in some application-server-wide, jboss specific way.
These are all examples that have come out after 8 hours of creating some very basic things with JavaEE. Nothing extravagant. And the application is totally non-portable. So don’t give portability as an advantage of JavaEE. Perhaps the only portable system is a Hello World.
But portability is not the worst thing. The worst thing is that the principle that at least JBoss follows is the “principle of most surprise”. Things just don’t work the way one expects them to. Perhaps I’ve been spoilt by spring, but I expect:
- to be able to configure options per-application (and not per-application-server). Preferably with some standard XSD that would allow auto-complete. Topics, Queues, DataSources, etc – all of these don’t appear to have a standard way of configuring. And JBoss lets you configure them on application-server level. When I tried to put my datasource definition in META-INF an exception was thrown that the datasource is already defined. Well, I didn’t have time to debug why it discovers it twice.
- to be able to accomplish simple tasks in simple ways – this is becoming more and more true coming from J2EE to JavaEE6, but still from time to time one has to kill flies with shotguns.
- to be given meaningful exception messages – cryptic exceptions, with bad English, including long numbers and telling simply that something failed, but rarely what, and almost never why. As a contrast I’d like to give an example from spring I was fascinated with the other day – I mistyped a bean name in my mappings (singular vs plural), and spring suggested the correct name.
- to work with something stable – NullPointerException is quite a “bug”.
- to see adequate logging – logging that a timer has timeouted or that onMessage has been called with log level of ERROR is … odd.
Now, you’d say, most of these issues are only JBoss related. I really hope WebLogic, WebSphere and Glassfish are better. But the fact that most of these things are left to vendors to decide, and they have most often taken decisions in the light of J2EE (pre-Java5), which are retained as philosophy – tons of deployment descriptors and scattered properties. Virtually random JNDI paths. “Frivolous” interpretations of the (unclear) specification.
What spring does instead? It doesn’t have a specification to implement. It has evolved naturally to the state where it meets all requirements in the most straightforward way. It has extensive and clear documentation and examples. It is working properly, following the “principle of least surprise”. It has support for everything that you get by an application server – messaging, transaction management, etc. And even more, actually – it has classes and utilities that make working with other technologies (jpa, hibernate, JMS, etc) easier and simpler. Well, of course it’s not all roses with spring, but its flaws are minor compared to these of JavaEE.
You may say here that application server provide essential production features like clustering, load-balancing, distributed transactions, which spring deployed on Tomcat (or any servlet-container) don’t have. Well, wrong. SpringSource created their tc server, which is a lightweight application server supporting many things that you need, but does not implement the JavaEE spec.
Furthermore spring has influenced and continues to influence most of the JavaEE specifications. It is at least a few steps ahead by definition.
Another argument might be that application servers are commercially supported, while tomcat + spring may be suitable for some small organizations, but not for “our big and responsible company”. Well, wrong again – SpringSource offers commercial support. If you are going to try the argument that you don’t want to get tied to a single provider, re-read the first part of this post.
As it seems, I am favouring spring and its subprojects. What I see as problems with JaveEE compared to spring are:
- JavaEE is being specified formally in big time intervals, rather than evolving steadily like spring. Thus major flaws take too much time to fix and workarounds become accepted practices. Not all cases are covered by the specifications which leads to the need of proprietary solutions. (one example – lack of delete-orphan or collection-of-elements in JPA pre-2)
- JavaEE specifications are prone to misinterpretation.
- Application server vendors actually aim at providing their custom configuration options and “quirks”, so that customers can not easily change them for another vendor. Spring doesn’t have this issues, since it is the only “vendor”. While this might sound like the same thing, it isn’t – as I mentioned above – try running the Sun tutorial on JBoss. Resources are separated and are only application-server relevant. You may find a tutorial or a solution to a problem of yours that works on WebLogic, but doesn’t on JBoss.
- Application servers are not well-written. That’s subjective opinion, but I find JBoss of low quality (see above), (and spring of very high quality). This is due to a number of reasons, including backward compatibility issues, corporate decisions, etc.
The conclusion would not be blunt. JavaEE is developing and it has its power. It definitely should not go away for at least one reason – its inadequacy has brought great frameworks like Hibernate (certainly better than entity beans) and spring (certainly better than EJB pre-3), which in turn have influenced back JavaEE (JPA and EJB3), and the process will keep going, for the better.
Interesting… 🙂
You said: “So when you use @Resource(mappedName=”..”) your application automatically becomes non-portable, and application-server dependent”
Isn’t there a mistake? Don’t know about JMS but i think the mappedName applied to EJB3 remote services guarantee that the same JNDI name will be used for any application server no?
When applied to your own beans – yes. But if you want to refer to any container-defined objects (like a JMS Topic or Queue) – then JBoss defines them in “topic/yourTopic”, glassfish in “jms/yourTopic”, and others – who knows how.
JNDI names have been normalized in Java EE 6.
I think you’re jumping to conclusions based on a single product experience.
Which version BTW? JBoss hasn’t released their Java EE 6 server yet.
JBoss 5.1. Yes, I noted that I hope other implementations are better. And I also noted that JavaEE6 is an improvement. But JavaEE5 was supposed to be a huge improvement as well (it was, but did not solve everything).
The above indeed discusses JavaEE5, but I tried to outline fundamental problems that will hardly be fixed. I’m looking forward to being proved wrong 🙂
Another spring fanatic I see. While JEE will get no roses, spring is amongst the most over-hyped pieces of bloatware I have had the misfortune to work with. It keeps dragging in more and more dependencies for doing the simplest of things.
I am keeping a bet that in another two years or less, there will be a backlash against spring and people will start referring to these dark ages as the days of ‘spring hell’.
Please refer slide 2 of 18 http://www.slideshare.net/johaneltes/java-ee6-cdi
intresting read. we had similar experiences while trying to port apps from Glassfish to Weblogic in past.
It’s really pointless comparing Spring and JEE and I sincerely hope this is the last article of its kind I’ll ever read.
Spring is a product (backed by one company) and JEE is an attempt at creating a standard – which has its own drawbacks as we all know. It’s certainly easier for one company (as Microsoft, Apple and others have shown) to drive the development of its product(s) than it is for a standards-setting body bearing in mind that everyone’s interest has got to be protected.
Granted, Spring has brought a lot to the Enterprise table and JEE is better for it, but frankly that’s what products are meant to do – help drive standards.
However, what I find perplexing (and annoying these days) is that all these Spring fan(atic)s make it seem like SpringSource invented Enterprise Java! We don’t ever hear someone like Gavin King reminding everyone where JPA came from. And why hasn’t SpringSource invented it’s own version of say JDBC, JMS, JTA and all the other technologies that Spring would in fact be useless without. But it can’t and shouldn’t as there’s really no sense in re-inventing the wheel.
I’m sure you can get by just using Spring so you don’t have to touch JEE. The choice is yours – use whatever is appropriate for the task at hand – a lesson one usually learns with experience. But bear in mind that if you ever have to deploy to Tomcat, you’re using JEE because the last time I checked, Tomcat was based on the JEE specification, albeit a subsection of it. Enjoy.
@PaulK
I’m comparing spring to JavaEE because these are the two alternatives nowadays for making (enterprise) software – you either for for an application server, or for spring+tomcat.
The point about tomcat being JavaEE – of course it is, but what I’m talking about is JavaEE X certified application servers, and their implementations of the standards.
And no one said spring invented the enterprise. But Rod Johnson was the first to employ dependency injection, it turned out great, and you see the result. Actually spring offers pretty nice support for good JavaEE technologies, like JMS and JTA. So what spring actually did is: 1. replace EJB, 2. made it optional to use full-blown application server, with all the unwanted stuff there. Now, the web-profile is trying to get the 2nd point, and CDI is trying to get the first. I happen to be more or less fluent with CDI, it’s pretty nice, but I see some drawbacks that I’ll perhaps discuss in another article. (no one is forgetting Gavin King, Hibernate did to entity beans (more or less) what spring did to EJB. But due to political reasons (hibernate is now jboss/redhat) Gavin is participating in standardization, while Rod is on the other side. It could’ve been the other way around, though.
@Karthikeyan C I’m giving a presentation on CDI next week. I’m aware what’s its aim in JavaEE, and how it compares to spring.
@Tarun Elankath
Have you bothered to check the maven dependency graph of spring 3 jars? You get only what you need, no more. You start only with 2 jars, and add modules, depending on whether you want jms, jpa, etc support. So calling something “bloatware” because it provides optional support for many many technologies, making them very easy to work with, is not a very adequate comment.
That’s what I don’t understand – why have people started recently to take JBoss’s word that “spring is crap because it has so much in it”. It’s logical for JBoss to do that, because they are competitors. Gavin King once said – “I have things to say against spring and guice, Bob Lee has against CDI and spring,and Rod Johnson has against CDI and guice – it’s normal”. Take a look at CDI. Very good specification and a promising framework. However it lacks some features and integration with technologies, and here come the portable extensions to help. But check Weld’s portable extension page – many of them are actually “unportable” extensions. So what do we have – a myriad of extensions, some of which non-portable. Aren’t we getting at what spring is?
I’m not a fanatic, because I’ve used both, and preferred one over the other for reasons partly stated above. While on the other hand you repeat someone’s (Gavin’s) words without actually looking into the dependency graph of spring. Eh? 😉
I see nothing controversial about this post, except for the likely confusion it causes by the “Spring vs. JEE” theme. There is no – and never has been – a contradiction between JEE and Spring. So, I see no need for name calling or attacks of any sort… Spring came about to simplify (significantly) enterprise Java development. And it does a great job doing that. Anyone who appreciates the art of programming can see the benefits Spring brings to the table. As someone has already noted here, Spring makes good use of many JEE technologies implemented on specifications. Instead of replacing things that work, it makes it easier to use them. It also makes it easy to choose and switch between implementations without any impact on the business logic or application infrastructure.
Instead of forcing clunky interfaces and constraints (such as EJB2) Spring allows and promotes using nothing but ordinary Java classes (POJOs), programming to interfaces, and, for that matter, encourages and simplifies writing better software by utilizing and enforcing the best programming practices.
Now, the fact that each JEE vendor has always been adding their own goodies (or ways of doing things) to the standard spec has never been a secret. Therefore deployment configurations vary from vendor to vendor. Spring allows you to build app-server-independent applications, and use configuration to wire the app-server specific resources, txn managers, messaging implementations, etc. Of course, this means that the same WAR file, for example, may not work in all app servers/containers. So, you might need unique configurations for different app servers. The point is, your applications logic should never depend on any vendor-specific components, and just work with whatever implementation is provided at the time the app is built or/and deployed. Spring makes that possible and easy.
SpringSource’s tc server is just another alternative for developers to consider. And it is a very good alternative. There’s no love lost between SpringSource and Red Hat, and tc server is there to compete with JBoss, obviously. In the end, you can choose whichever you like. The author states his personal preferences, and I see his point.
Cheers.
@Constantine
Here is someone who understands the matter without extra “feelings” 🙂
Apart from stating my preference, I wanted to point out that portability should not be considered an advantage of JavaEE (5 at least), as it is claimed. But if you are willing to stay non-portable, and feel more prepared to work with EJB than with spring, then it is workable, of course.
There is nothing wrong with this article except the fact that it may be misleading due to the fact that Java EE 5 was released on May 16, 2006. Which was over 4 years ago.
Java EE 6 is miles apart. IMO, This should be clarified early and boldly at the beginning of the article.
Lincoln, JBoss Seam Dev (for the sake of openness)
Also, any judgments of the JBoss AS 6 server should take into consideration the fact that it is still Beta.
🙂
I do enterprise Java programming everyday. My organization is very large, we have dozens of applications running in SOA architecture powered by in-house Message Oriented Middleware.
The fact is, that in this kind of architecture we gain almost no benefit of using J2EE and heavyweight application servers. Developers naturally tend to choose and advocate for Spring, because J2EE is just lot of hassle to deal with.
My thought is that you should work with tools you are comfortable with. If J2EE fits your architecture, that’s great. I see that J2EE offers lot of functionality out-of-the box, and Spring is extremely flexible, with cost of extra verbosity in configuration.
@Lincoln – I added a note in the beginning. Indeed it is worth mentioning.
One more thing – here’s my take on Spring bashers…
http://constv.blogspot.com/2010/10/spring-aficionados-vs-spring-bashers.html
Use Glassfish. Life is too short for JBoss.
I know. I’ve used both.
@Koppernicus it is to be noted that Glassfish uses JBoss’ implementation of CDI (Weld)
trust me, weblogic is much MUCH worse.
it likes to pull in half the internet’s java libraries, modifiy them and remove versioning of them so that you end up with constant class not found, method not found etc. its the absolute worst.
The author is right indeed about JNDI names before Java EE 6. In JBoss, it’s different. I think that you can configure JNDI resolution but still why would you?
I would still stay that Java EE is good when ;
– companies need an integrated solution: You integrate JAAS security, JMS, SOAP services for free instead of mixing multiple middleware solutions.
– companies are committed to few specific Java EE servers(Websphere, JBoss, Glassfish, etc.). “We ship only on JBoss and Glassfish”.
– The work “Enterprise” still means something different in the corporate world. For many clients “Java EE” means built and ready for the Enterprise, so it sells easily, compared to other “mix-ins”.
– Many big companies avoid the framework hype and want to stick to standards and core libraries, so it’s difficult to bring X and Y libraries without tons of discussions and negotiations.
The thing that I liked in JBoss is the datasource descriptors ds.xml : I’m not sure that you can do that in any other j2ee app server(inside the deployment descriptor, to be more specific).
The JBoss console was and probably still is one of the most “primitive” out there. You couldn’t setup directly painful configs such as clustering, while you do it in few clicks in Websphere and Glassfish if I recall correctly.
I was hoping that jboss 5.x would provide ordering that works for services and referencing, like A depends on B, inside an ear archive. If I recall Java EE 6 will provide optional ordering.
Is JavaEE still relevant and useful? I would say yes, but only for big companies and big projects. Small to medium companies only care about basic subsets of JavaEE and go for a mix of frameworks with a servlet container.
As a developer, I have worked in many enterprise applications, one most common thing is, Portable is not issue. Applications are built when the product is purchased and licensing are pretty much sorted out.. So porting enterprise applications from Oracle Weblogic to Jboss every now and then is not common. So JEE will sell quick than Spring. I have worked with Spring and it is breeze to setup and run any app quickly, and more easy to integrate with existing apps.
Now a days I am using Seam (more proably JEE6 when it is out), purely bcos the company decides to go with single vendor and its products.
So point is, personally Spring is great..but Commercially JEE will sell good.
Very nice article and good comments, but I have one question how cloud will affect both of these technologies?
The cloud is rarely influencing the underlying technologies. You can run anything in the cloud. We are currently having a spring project in the cloud, and I know of JavaEE projects there as well. So it won’t change the picture.