Rob Williams is a probabilistic Lean coder of Java and Objective-C. Rob is a DZone MVB and is not an employee of DZone and has posted 171 posts at DZone. You can read more from them at their website. View Full User Profile

Java Stack Refresh: Like Root Canal Without the Anaesthetic

  • submit to reddit

Yesterday, while spending hours trying to get a new app to deploy on JBoss AS 5.x, I started realizing, ‘hey, maybe we should open a car factory where people could just come in and like, pick the parts they want and stuff, because then, they would be free and stuff.. so like they wouldn‘t have to accept a car with all 4 quarterpanels the same color (so bourgeois)...‘ That‘s kind of what JEE is like.

The problem with JEE these days is that instead of focusing on what is required to make a solid, complete offering, the round of specs are really sketches of general points of consensus, and the really hard part is left to each implementer. Surprise announcement: only a few are even able to do it (*Oracle* and RedHat) and they are not very good at it. I am a fan of Red Hat, and though I think it's hard to argue that there is anyone else to consider if you want a really complete offering, unfortunately, Red Hat has their own faults, and surprisingly, they make them seem like the usual sluggish purveyor of standards-based progress. Sad thing is, in Red Hat's case, their faults are pretty stupid. Yesterday we spent hours trying to deploy an app because JBoss is still doing monolithic bundles, and if you need to depart from their path, you are on your own. For instance, be prepared to go through the m2Eclipse dependency graph excluding stuff, marking things as provided or scoped to compile. But that's not the end. JBoss AS ships with Hibernate. So if your project uses a different version, plan to spend a bunch of time fishing your jars out of the maven repo, renaming them of course, oh, and remember, you'll have to do this for every instance you want to deploy to. Of course, all the ugly, familiar ghouls trot out of the graveyard as soon as you head down this lane, and none is uglier than XML: hasn't a decade of looking at xerces incompatibility errors enough?? Seriously, you know you are at a low rung of hell when that bell rings in your ear for the umpteenth time..

Here‘s the part that really makes me think we‘re all doomed: Red Hat is a large company with revenue. I think it‘s safe to say that had they been willing to have a single person work on this problem, maybe 2, they could have licked it a few years ago. Does this get filed under hubris? Maybe not. Probably more just garden variety myopia. But it also goes to show one of the main arguments I have been making for years here, under the banner of freedom, we write ourselves passes for progress rates that can no longer even be called glacial (in part because they are slower, and also, thanks to global warming, glaciers are disappearing faster). They claim that they are going to take this problem off the table, but when? I am not even saying Maven is the only way, but really, it would not have been hard to create a bloody archetype to go with each target environment. And while I am saying Maven could have helped, its facilities for these types of things are underwhelming, which would have been ok, except that they too have been riding the same glacier scree. (I want to find another build tool, and may even consider the use of Groovy at this point, Maven, while better than Ant, is not enough better…) I‘m burned out on its many shortcomings (another post) and the poor state of tools.

We ultimately failed because we had JSF 2 in our new app. I found a guy on the JBoss Community site who said go get the jboss-faces jar out of the 6.x milestone, but that just led to another error about the templating code.

Finally, after the anger subsided, I started to think again that perhaps Java is going into a death spiral. There really is no substitute for a complete offering that is seriously tested. Red Hat is the last chance that this will ever happen. I am hoping either they pull it off, or Apple takes my prior advice and figures out a way to make a cocoa web framework.



Published at DZone with permission of Rob Williams, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Yannick Menager replied on Thu, 2010/06/17 - 3:41am

I used to use jboss quite a bit in the old days, I gave up because it's very very crappily implemented.

 In fact "steaming pile of manure" are the words I generally use, although i must admit it's probably a bit harsh

 I've been using glassfish in the last few years, which i find significantly better that jboss

Ryan Developer replied on Thu, 2010/06/17 - 8:17am

I also migrated from JBoss to GlassFish a few years ago. The main reason was that every time the JBoss Windows service would start it would only partly start because a bunch of ports it tried to use somehow conflicted with something else.  Restarting the service after Windows booted up would always fix the problem.  I haven't had this problem with GlassFish.

Also, any time I wanted to do some administration I had to search Google for some obscure bit of XML or plain text to put in a new file I have to create myself or add somewhere (same deal wtih Tomcat).     The web based admin GUI + command line asadmin tool puts GlassFish ahead of JBoss IMO.  Full featured, discoverable, intuitive administration is really important to me.  Maybe they've improved that in JBoss AS 5 or 6?  Even though I'm not a JBoss AS fan, I must say that I really appreciate other JBoss projects such as Seam and RichFaces.

If you rely entirely on Java EE APIs (like using JPA 2.0 instead of using Hibernate directly) then you won't be including 20 MB of jar files in you project which eliminates classloader hell.


eduardo pelegri... replied on Thu, 2010/06/17 - 9:36pm

Don't give up on Java; give us a try...

GlassFish just released 3.0.1.  The Open Source distribution is available as GlassFish Server Open Source Edition while the commercial distribution is Oracle GlassFish Server.  Although Oracle will only support the Oracle GlassFish Server distribution, the OSS version is of the same quality.  Actually Oracle GlassFish Server only adds a few branding elements and a couple of add-ons.

   - eduard/o

Ivan Lazarte replied on Fri, 2010/06/18 - 3:20pm

Java is great. Maven? Nope, JBoss? Usable. EE standards? Definitely arguable. Nothing wrong with stripping what you need to core Tomcat or Jetty and going with Spring.

Michael Remijan replied on Fri, 2010/06/18 - 3:52pm

I have not migrated to GlassFish for a couple reason.  One, I have not had time to do work on it. Two, I am anticipating moving to a different EE server will be very painful and time consuming so I am avoiding it.  I still do not understand why anything part of the server (whether it be hiberate or xerces) has any impact on an application deployed to the server?  Isn't each application suppose to run in it's own class loader bubble seperate from everything else?  I know easier said than done but after all these years of building app servers....

Ryan Developer replied on Fri, 2010/06/18 - 4:55pm in response to: Ivan Lazarte

> Nothing wrong with stripping what you need to core Tomcat or Jetty and going with Spring.

True, and there's also nothing wrong with using only the pre-integrated light weight Java EE APIs your application needs, and running in a small, fast, light weight environment like GlassFish V3 Web Profile which only loads what you use into memory, and offers full featured administration.  GlassFish V3 web profile is only 33 MB.   One of my apps that bundles external dependencies inside the .war file (Hibernate, Spring, web framework, etc) + Tomcat 6 is the same size. In a Java EE environment I save a lot of time because I don't need to configure/integrate/debug the various libraries and frameworks -- I just use them.


Ryan Developer replied on Sat, 2010/06/19 - 11:28am


Here is a detailed explanation of GlassFish V3 ClassLoader hierarchies, and how to circumvent them when necessary:

I have a legacy app that uses Hibernate instead of JPA.  When I ran it on GlassFish V3, Hibernate would no longer initialize.  It turns out that GlassFish V3 uses a newer incompatible version of asm.jar.  This was the first time GlassFish jar files have ever cause trouble for me.  The two solutions I found were:

1) Quick and easy solution: add a proprietary sun-web.xml to my project, and put   <class-loader delegate="false"/>    in it. If I ever migrate to another Java EE app server, I'll have to re-visit this problem. 

2) Long term solution: Completely remove Hibernate from my project and use JPA 2.0 APIs which are portable to all Java EE 6 certified application servers.  It doesn't matter if app server vendor A uses the Hibernate JPA 2.0 provider, and app server vendor B uses the EclipseLink JPA 2.0 provider. My app won't bundle any JPA provider .jar files inside the .war because everything it needs are made available throught the Java EE ClassLoader hierarchy.

Java EE 5 cleaned up underpsecified areas that caused migration issues.  If you are moving a pure Java EE 5 application to a Java EE 6 server, I think migration issues will be minimal to none.  For example, you may be using JPA provider specific query hints (such as caching and pessimisting locking), criteria API, the external facelets library, etc.  Now that this functionality has been standardized, it is best to use the standard APIs & the provider that comes with your app server so you can avoid migration issues in the future.

Smeltet Kerne replied on Sat, 2010/06/19 - 11:07am

>I am hoping either they pull it off, or Apple takes my prior advice and >figures out a way to make a cocoa web framework.

If apple do that then they will make it very hard for you to replace their APIs with your own alternatives. But if you think you can live with the limits that apple will put on you why can't you live with JPA and the default XML api in JavaEE? Are you sure theres any rational reason to replace them with Hibernate et al?

It's also a little puzzling why you expect Redhat to change the paradigm of JBoss. Redhat OS has stuff like selinux for security - it definitely not for the carefree administrator - how many can actually wield this thing correctly? And Redhat JBoss has a multitude of services running on the HTTP port by default and a mess of halfbaked wikis about how to plug the holes. In this and many other regards Redhat OS and Redhat JBoss are perfectly aligned. They are not for the carefree user/admin - on the contrary you have to spend loads of time tinkering with their inner workings just to make them do basic stuff.

Don't get me wrong we have all felt the pain of Java class loader hell but when you go outside the JavaEE envelope then it dosen't look like you're actually that interested in carefree software development. JavaEE cannot make any promises that migrating apps that depend on proprietary stuff will be easy or possible.

Stephane Vaucher replied on Sun, 2010/06/20 - 11:16pm

I'm not sure I understand the point of this post. You are using open-source software and you have observed a problem. You can try and use free support, you can correct the problem, or you can pay for support. Otherwise, you can go with another J2E vendor. Saying that "their faults are pretty stupid" is very much counter-productive and you sound like a lazy grumpy old man (which I'll assume you aren't since you post here). I just hope that you opened a bug report describing the problems you observed with replicable steps.

J2E is a standards-based solution for a specific category of problems. It is normal that it provides parts as these different parts correspond to different aspects of these problems. As a developer, you still need to do some work to make sure you choose the "right coloured" doors for your your system. If you can't find four such doors, you get a door and paint it yourself.

Java is not going into a death spiral. If you really think you are doomed because J2E does not satisfy your requirements out of the box, then you really need to take a breather and take a vacation.

Rob Williams replied on Wed, 2010/07/07 - 10:11am in response to: Stephane Vaucher

The point of my post is very plain, let me boil it down for you, since you clearly missed it: 1. OOBE is an important measure in the development world. 2. Time spent not on your product is time wasted (Lean). Time wasted by a lot of people on the same things is a form of gross negligence. 3. The overall point to a lot of my posts these days is that quality requires some process of being serious about ensuring it as part of an overall offering, which is not happening in the Java world, hence, a decade and a half in, quality is still very low. The real question is what's the point of your post. Egotistical, ad hominem witlessness. I bet the same boss that pays you to run around documenting things that don't need to be documented pays for your hard earned vacation after you're done sweating through a bunch of those trying, difficult undertakings. You take care of yourself; the community would be hapless without you.

Michael Eric replied on Wed, 2012/09/26 - 3:41pm

I've already tried migrating from JSF 1.2 to 2.0 and had a few issues. I suspect there were underspecified areas of JSF, because the things I had to change made me realize I wasn't doing something cleanly/the right way in the first place and that JSF shouldn't have let me do that. I don't remember specifics anymore.

linux archive 

Rehman Khan replied on Sat, 2012/02/25 - 4:27am

I like that idea, Ryan. I have noticed a lot more people seem to be using Glassfish. Are you using it in eclipse?

Made more progress today, but Java is in a mess right now, that's for sure.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.