Link Details

The title of the article is misleading.

I'd rather say, "the title of the article is sarcastic" ;)
,

So finally, after 20 years, J2EE development is "easy" thanks to Glassfish? Congratulations but.. too late.

J2EE in 1990? Is that what your resume says?

Title is misleading, just for any folks out there who are looking at this article.

I think you're true. It seems the first spec of servlets was from around 1997. Well, then I'll be back in 13 years. In the meantime, I can solve my customer's problems faster than you can say
"OpenSessionInViewFilter". Don't take me wrong. I really like it, and I wish I could use it, but I just can't afford the cost. What I feel is normally called "fustration" :)

This post, and similar posts by Oracle and former Sun employees, reeks of desperation. The enterprise Java space voted 'no' on J2EE/JEE years ago. Go to dice.com and do the research yourself.

You read what you want to :) I think it bleeds new hope, but hey, different perspectives right? Enjoy ;)

Dice.com search results:

"Tomcat" - 1307 results
"GlassFish" - 78 results :-o
"JBoss" - 1139 results :)
"WebLogic" - 1746 results????
"WebSphere" - 2322 results???? darn
"Spring" (Which runs on all of these BTW...) - 2480 results

Next comment? ;)

Taken those numbers as they are, it means Java EE might be used a lot more than Spring ;)

Only two well known implementations like JBoss and WebLogic already outnumber it.

The change takes time! Companies will still use old J2EE 1.4 application servers for a long time.

Just curious, if you try J2EE with dice.com you can get 5095 results.
How about that :P

[moved]

Focus on 'ejb3' and 'jpa', in lieu of app servers, to get a better idea of the job demand for JEE. Because it's not about the app servers; instead, it's about the JEE specifications being used by developers. For instance, many companies deploy just war files on the above app servers, eschewing all JEE features less servlets and jsps, which explains the heavy demand for Struts maintenance work. Also look at the demand for Hibernate to see how JPA has yet to take off.

Needless to say, Sun, Oracle, IBM and JBoss have made a heavy investments in JEE. Yet developers, over the past 7 years, have been steadily leaving JEE for more productive light-weight technologies. And it's difficult to see how those developers will ever return to the JEE space. Of course, only time will tell. But, for now, the job market numbers don't add up to a JEE comeback.

Finally, JEE cheerleaders have had a tendency to do more harm that good. The guy from Oracle, for instance, is simply obnoxious (see TSS threads for more). And let's face it the reputation of JBoss went into the toilet years ago.

JMS - 1097
EJB - 977
JSF - 692
JPA - 182
JTA - 35
Hibernate (Implements JPA2 btw) - 1865

Wicket - 45
Grails - 85
Rails - 391

Ok...

Not 'ejb', but 'ejb3', which should get you 58. Yes, Hibernate implements both JPA 1 & 2. I actually love using Hibernate, JPA & Hibernate annotations and a nice custom generic entity manager. It would be interesting to know how many Hibernate developers use JPA annotations. Once Hibernate 3.5 goes final, I suspect more developers will use Hibernate & JPA2 annotations. It's interesting how the other JPA alternatives have never caught on.;)

I agree with webmascon, the title of the article is misleading, but it's a good article.

The more and more I learn jee the less I like it. The larger the app, the less it applies. I'm not angry like the article says I would be, I just know he's wrong.

I think more people keep calling their apps jee, but in reality its a hodge-podge. It just looks good on the technology list, but in reality people need to get things done and true a-la-carte frameworks like spring make that happen.

don't even get me started on jsf. talk about solving a problem no one has - no except people who don't and aren't willing to understand html+css+js.

I think you are very, very wrong.

We have a medium size app (several 100k LOC) and initially it started with business code on JSP. This very soon became terrible to maintain. We tried some of the other frameworks out there, and eventually went for Java EE 5 and have been gradually rewriting the old JSP/JDBC based code and some of the code written with other frameworks.

With Java EE 5, everything became so much better and easier to maintain. We have a clean view page (JSF/Facelets), a thin backing bean that is injected with EJBs, that are very simply POJO classes and concentrate on the business logic. These have an injected entity manager which makes accessing the DB via ORM a breeze. The methods of the enterprise bean are transactional by default and this transaction transparently propagates to methods called by the enterprise bean.

This relieves us from so many tedious concerns, that development has become really fun again and we're getting things faster done than ever.

Both JSF and EJB are absolutely key aspects in this. You're crazy if you think it solves a problem nobody has. JSF allows us to do a very clean separation between conversion and validation of input, managing scopes, informing the user and calling into the business logic. Because of the popularity of JSF, a great number of components is available for it, which we put to great use. Things that would cost us days, even weeks, with other frameworks are now just seconds with JSF!. We add the jar with components, import it into our page, bind it to some data from the backing bean and it just works.

Were Java EE 5 already worked very well, Java EE 6 absolutely improved on nearly every aspect. Especially CDI and the conversation scope, which has excellent integration with both the web and business tears, is a superb tool that is applicable to many of the problems inherent to multiple tabs/windows and flow between different pages.

You're one 'single' case in point. I never said it doesn't work for the very few. But how am I wrong about the long downward trend of JEE?

>But how am I wrong about the long downward trend of JEE?

Brother, you're dead wrong. Since Java EE 5 the trend is clearly upwards. Shall we talk about the long downward trend of Spring instead?

Sure the JEE trend is up from zero. But how can I build a consulting business on top of such a small trend line? I don't think I mentioned Spring on a thread about JEE, did I? I suspect this thread has run its natural course. So why don't we all just sit back and let the market decide. Fair enough?

Sure, but don't forget that WE are the market. Whatever we use to choose is what the market decides.

And I don't think the Java EE trend was ever zero, apart from before it existed of course. Far from it, although it indeed reached an all-time low after the dreaded J2EE 1.4 release. You know, the one that gave us 'gems' such EJB2 and JSF 1.0. But ever since Java EE 5 was released it seems to be increasing rapidly. This is noticeable in many areas: number of other projects providing extra services, components and extensions for Java EE, number of books about Java EE that appear in stores, number of applicants that has experience with any of Java EE's technologies (JSF, JPA, EJB, etc) on their resume, number of job listings asking for Java EE developers, number of blog postings on the subject, etc.

I would love to see some serious research about what Java developers are really using, but personally I see nothing but an increase in uptake. Maybe people were still hesitant right after Java EE 5 was released, but the verdict if pretty much there right now that Java EE 5 was a pretty solid release. Now the JCP for the second time in a row has delivered an excellent release, so I see little excuse for still being hesitant.

Where you build on consulting business on top of is your own choice, but looking around and just trying to pick the best platform for developing our applications on, Java EE 6 ranks pretty high.

I'm guessing you're an employee, not a businessman. And that's fine. As a businessman, though, I must measure market demand for a technology to deem it worthy of my time and money. In other words, I must identify the winners and losers in the marketplace in an effort to survive.

When JEE5 debuted, I religiously monitored 'ejb3', 'jpa' and 'jsf' job opportunities. I even did a jpa/jsf project, which turned out to be a hibernate/jsf project. But ejb3 adoption has yet to take off in the marketplace, which the dice number clearly shows (58 current opportunities). And jpa and jsf have been a disaster, when the rubber hits the road. Admittedly, JPA 2 and JSF 2 correct a ton of well-known faults. And if market adoption ever picks up, I'll be there.

In effect, I'm a market capitalist. Consequently, I can't afford the luxury of being a zealot. I can support only what the market demands. Can you appreciate that? Rest assured that if JEE6 becomes wildly successful, I'll quickly become a huge fan.

Sure, if you're a market capitalist, things might indeed be very different. I don't have any hard figures on actual adoption and definitely no desire to persuade anyone in your position to bet your money on whatever technology. That's entirely up to you.

I am however a lead developer, which means I have a strong responsibility to both the company I'm working for and the individuals in my team. If I would choose seriously wrong, then this would directly harm the company. We wouldn't be able to recruit any people skilled with said technology, development might grind to a halt and run-time stability could go down the drain. On top of that, it would also decrease the personal value of the programmers in my team if I let them learn a technology for which there is very little to no demand elsewhere, and they eventually want to leave for another job (management wouldn't care for such an argument, but I feel lead developers should care).

With Java EE however none of this has happened. We build our interface with JSF and it works absolutely great. It helps of course that I know my way around JSF and can teach the other team members about how to avoid the pitfalls, but it absolutely has not been a disaster of any kind. Our product is getting better with every release and our customer base is still growing. This is thus far from a disaster.

Some random things that are great about JSF are for instance the dominant place of conversion and validation in the life cycle. Before using JSF, a lot of pages were doing a lousy job at validating user input. After JSF, this has improved a lot. We use a moderate amount of AJAX in our product, and at places were we use it, its absolutely trivial to implement. A little a4j:support tag on a strategic place and we have a fully AJAX enabled component. I don't know what can be simpler than that really. Another great thing is the availability of high quality components (like e.g. those offered by RichFaces or PrimeFaces).

With JPA we're seeing a similar story. Originally we had a DAO layer implemented with a very lightweight in-house build JDBC wrapper that just allowed parameterized queries with named variables, simple programmatic mappings from an Object to a table and the other way around, and a very simple connection management. For simple stuff this worked great, but when you wanted to retrieve actual object graphs from the DB, it just became incredible complex and at times simply broke down. Back then we started introducing JPA step by step (there was just too much legacy code to change overnight), and really all developers were immediately enthusiastic about it. JPA makes managing relations between entities so much more easier, that it really is a clear winner. Sometimes JPA doesn't provide some functionality we need, like a second level cache and custom types (for DB specific types). At that point however it's really easy to just use some Hibernate specific functionality.

Finally, before using EJB, transaction management was kind of a challenge. JDBC based resource local transactions are just terrible, as are the native Hibernate and JPA transactions. As a result there was a certain amount of corrupted state in the DB. With EJB3 this is now so incredibly simple, that it's really not worth any lengthy discussion. We put a @Stateless annotation on the bean that is implementing business logic, and that's it. Methods on that bean are now fully transactional and propagate to anything else called from that method. I have no idea how things can be more simpler than that.

Clearly for us using Java EE has not been disastrous in any way. All the developers love it and our system is in great shape. I would love to hear some specific examples from you that made your JPA and JSF project such a disaster.

>>>

I spoke of no JEE6 disaster. I merely stated that targeting JEE6, until there is wider market adoption, is not a viable business option for me at this time. That you're a successful 'early adopter' is noteworthy. If we get to the 'early majority' phase, think 'crossing the chasm', then I will take JEE6 more seriously.

>I spoke of no JEE6 disaster.

Indeed you didn't, but I actually referred to this quote:

>And jpa and jsf have been a disaster

Have you actually done a project with those technologies that turned out to be a disaster, or do you mean that adoption in the market of them is a disaster?

I've used JPA 1 and JSF 1.*. The problems with each is well documented; hence, the significant changes in JPA 2 and JSF2. So, yes, I think adoption of both technologies failed to come anywhere near expectations, because both made development both painful and unproductive. I've worked on a couple projects that resulted in the removal of JSF. My experience is that Hibernate 3.2+ and JPA 1 annotations have been well received; yet, using the Hibernate API and select annotations is always required.

Hibernate 3.5 and JPA 2 look promising, and will most likely enjoy great success. The web app space, though, has become so fragmented that JSF2 will likely be too little to late. That said, the reviews of JSF2 have been very positive. Although, I find Cay Horstmann to be the most honest JSF2 user.:)

These days there are so many new technologies in the enterprise space being used to solve so many different and complex problems. And when simplicity is called for lightweight technologies are typically employed. Increasingly, JEE has become the odd 'man' out, either too heavy or not right for the problem domain. Moreover, developers have moved on. Fair or not, great technology or not, the greatest threat to JEE6 adoption is its legacy.

I have nothing more to say on this topic. Thanks for the conversation.

Okay, we could indeed talk for hours on, but let's leave it at this ;) Thank you too for the conversation.

p.s. it's also nice to see that there are so many votes for a pro-Java EE article and almost no down votes. Of course this doesn't mean that people who vote the article up are necessarily Java EE users, but still...