Rethinking Enterprise Java
Jul 21st, 2011 by sharps
JBoss AS 7 has been out for a week or so – probably not enough time for opinions to be formed but the feedback I’ve seen so far has been overwhelmingly positive. But that isn’t the subject of this post.
You probably didn’t see Red Hat’s press release as those things are typically only read by the press so I wanted to draw to you attention a single paragraph :
“JBoss Application Server 7 represents a major milestone in the evolution of Java application servers from complex and monolithic to more lightweight, modular and agile. This release will enable developers to re-think how they develop and deploy enterprise Java applications.”
I wrote that and I meant it. Over the last 5 years there has been a significant difference between the Java EE servers like JBoss, Weblogic and Websphere and Apache Tomcat. Tomcat has been the poster-child for the lightweight container movement (but we shouldn’t forget Jetty and Resin – both very capable servers) and has established itself as probably the most popular Java run-time.
But I think we’re at the point where there is no-longer a lightweight division between Java EE servers and Tomcat (and other Web Containers) – some good blog posts here and here that discuss typical developer requirements like startup time and deployment speed (make sure you read the comments). When we’re at the the point where we’re discussing sub-second differences between startup or deployment times then I think we have convergence. I think we’re at a point where you can no longer paint Java EE servers into the big, slow and heavy corner and Tomcat into the lean and fast corner.
Developers have more choice today than ever before – they can choose a lightweight container but no longer have to make a tradeoff between footprint and features. Or start with a basic server like Tomcat and incrementally build a full featured application server from the ground up as more features like caching, persistence, transactions, messaging, view layer are required.
OK before the Glassfish fanboys chime in – yes Glassfish did a great job of addressing light-weight needs for Java EE some time ago but by any available measure Glassfish still doesn’t represent a mainstream choice like Tomcat, JBoss, Weblogic or Websphere.
The problem, I think, is neither in startup times which are getting smaller and smaller nor in modularity which is getting more … modular, but in JavaEE itself. It says: “use the APIs, trust in hidden, sometimes closed implementations”.
The practice says – the implementation IS important and TCKs (and “JavaEE compliance” labels) should not be the only argument to trust in what application server provides.
Trust what’s in your WEB-INF/lib, don’t fully trust in parent classloaders.
regards
Grzegorz Grzybek
Grzegorz, I don’t really agree. There’s no such thing as “sometimes closed implementations”. In open source implementations of Java EE (Resin, GlassFish, JBoss AS, TomEE, Geronimo), everything is open source. It’s not sometimes open and sometimes closed.
If you only trust what’s in WEB-INF/lib, do you also put the JDK and your OS there?
One thing that I think is wrong with Java EE, is the tendency to have several applications in the same VM with a huge heap to deal with. I always thought that separating applications into isolated processes would work a lot better. It’s a bit trickier from an IPC point of view, but provides a lot more control. Currently you can do it manually with all app servers, but it is usually a pain to setup.
Having separate processes would allow finer grained control over access and memory (doing GC on several small heaps is better than doing it on a large one), and restarting an app is a lot easier. The amount of black magic that goes into proper classloading is staggering.
You could also even attach a debugger to an app without affecting others.
Statistics to prove your sentence about Glassfish not representing a mainstream, please. Don’t say just to say, otherwise we can classify you as a JBoss fanboy too
Ps: Show growing figures.
@Henk
What I meant was that JavaEE APIs implementations are more maintanable when you have them “close to you”. E.g. JAX-WS implementation should be a part of your App, not the application server. When such libs as: JAXB, CXF, Hibernate are provided by application server, you can’t really choose particular version – especially when there are many applications run on this server.
Thanks for reply. Of course I don’t put JDK into WEB-INF/lib
and @Juan
I agree – it’s usually better to have one application per application server – and when I went that way several years ago, I’ve discovered embedded jetty – powerful server which does what app server should be doing well – translate HTTP requests into javax.servlet.http.HttpServletRequests. And nothing more! If I want JMS, JPA, WebServices – I can add them to my application and I can be sure that the implementations are the same whether run in production or in Jenkins.
regards
Grzegorz Grzybek
Hildeberto, I am a complete JBoss fanboi – I Manage JBoss products at Red Hat
Here are some statistics on the App Server market :
Latest Eclipse Survey – Glassfish has 3% – same as “Don’t know”. This is a developer survey where GF is strong. In production its much less prevalent.
http://www.eclipse.org/org/community_survey/Eclipse_Survey_2011_Report.pdf
Another survey / popularity contest :
http://storage.pardot.com/1772/18317/Survey_Results.pdf
Glassfish is included in other in this report. I guess.
Also look at any Gartner EAS Magic Quadrant ior App Server market share report in the last 10 years – iPlanet, Sun AS, Glassfish have never made the leaders quadrant.
The criteria are more than just startup time. Startup time, memory footprint, redeployability, and ease of setup are all important.
I really like Virgo RT for redeployability, you code and refresh all day. Jetty seems great for a fast runtime.
But, developers want even more. It’s about a fast refresh cycle. Hence the play framework. It’s about being diligent to sip memory.
That’s why tools like JRebel even exist. So at the end of the day, catching tomcat in a couple areas is still not enough.