The single most important thing I've learned about Java EE while working with it for the last two painful years is:
UPDATE: ... is not to post something significant that relates to the work of people who you respect when very angry about something completely unrelated. Especially after a bad night's sleep and when rapidly approaching burnout at work. Except, of course, that I apparently haven't learned that.
I'll leave the following post intact and follow up soon (after sleep!), rather than edit it in-place. I know it's an unfair and unreasonable post in many ways, but I guess it's also thought provoking if nothing else. If you read on, be sure to read Markus Eisele's response, where he makes some good and important points.
A proper follow-up is to come. The original post:
"Final" or "Released" doesn't mean "Ready", only "Public Beta"
I suspect people are only now starting to use Java EE 6 for real production apps. There's been tons of hype and fire, but so many of the technologies have been so amazingly buggy I'm amazed anybody could build much more than a Hello World with them until recently.
When a new Java library or technology is released, resist temptation. It's not like a PostgreSQL release where you can immediately start working on it. It isn't finished. It isn't documented. It isn't ready. Ignore the hype and wait three to six months before going anywhere near it unless you want to be an unofficial beta tester and spend all your time reporting bugs. Like I have. Over, and over, and over again.
I haven't seen a single product released in a release-worthy state yet. I've seen a hell of a lot released quite broken:
- The whole CDI programming model was broken for the first six months to a year of Java EE 6's life, on both JBoss AS and Glassfish. Weld (the CDI RI) took at least six months after "final" release before the most obvious and severe bugs were ironed out, and was the cause of many of the worst bugs in Glassfish 3.x.
- Glassfish 3.0 was unusably buggy
- Glassfish 3.1 was still severely buggy especially with CDI projects until at least 3.1.1 + patches
- JBoss AS 7.0.0 was missing whole subsystems and didn't become usable until 7.1.1.Final, though it's FANTASTIC now
- Arquillian 1.0.0.Final wasn't really baked yet though at least it worked amazingly well once the deficiences were worked around.
- Mojarra is IMO only barely useful now, two years after release
- RichFaces 4.2.x was still biting me with bugs whenever I tried to do anything with it. Unicode bugs, CDATA/escaping bugs, lifecycle bugs, you name it.
- Seam 3 was released as "3.0.0" when only some of the modules worked, and those only for JBoss AS. A year after release it's pretty solid, but if you tried to use it in the first few weeks or months like I did you would've suffered - esp if you tried using it on Glassfish.
Seriously, be ultra-conservative if you value your productivity.
Glassfish is still buggy http://java.net/jira/browse/GRIZZLY-1252 and you don't want to know how many fixes where applied to JBoss AS 7.1.1 to make it EAP 6.
ReplyDeleteSure, but everything is buggy. That's software. And hardware, for that matter.
DeleteThe issue I had with Glassfish was that many of the bugs I encountered were "WTF, how can this have made it to release" bugs. Like the inability to call an inherited method on a CDI managed bean. Seriously.
My opinion is increasingly just that Java EE is too big to do proper QA on and still get a product out. The "test surface" is immense, and the combinatorial problem created by the vast number of modules and options makes comprehensive testing nearly impossible. You can test common scenarios well, but edge cases are going to lose. The trouble is that every different app is going to land up hitting a few of those poorly tested edge cases.
I don't have a good answer for this problem. Java EE's size, functionality, and flexibility exist for good reasons and are what make it attractive. They just make testing it a nightmare.
So in other words, is JBoss AS over Glassfish as the better solution when it comes to Java EE applications
ReplyDeleteThat depends entirely on who you ask. I've had better results with JBoss AS 7 than with Glassfish, but I'm sure others have had the opposite experience. AS7 certainly isn't frustration free - container managed security policy isn't very solid, and it's a bit of a PITA to swap out the persistence provider if you need EclipseLink instead, for example.
DeleteWhat sold me on AS7 was its module system. I just don't see PermGen space related memory issues anymore, no matter how often I redeploy. No more leaking-until-it-crashes behaviour. I don't have to restart the server much as a consequence, and when I do it only takes about 2s. I see almost no clashes between libraries deployed in a .war and libraries in server modules, something that caused me regular pain on Glassfish.
My personal preference is JBoss AS 7 - but I prefer to use EclipseLink (for better fetch control features and hints) rather than hibernate, making AS7 somewhat less ideal. I'm helping to improve the EclipseLink-to-AS7 integration to make EclipseLink a drop-in component, and once that's done I think it'll be an ideal platform.