And Eclipse doesn't yet count as its enterprise development frameworks, plug-ins, and tools in the new Eclipse Callisto are based only on J2EE 1.4 standards, still.

Well, JEE 5 really isn't out yet so to say that anything is compliant is kind of deceptive.

We use Spring/Hibernate at my current job. That's really it.

There are lots of libraries out there for different reasons, which may be what you're alluding to, but I think that's great for the ecosystem, though it can be confusing. In fact, many of the features of JEE 5 owe a lot to other frameworks. EJB 3 is essentially Hibernate from what I understand, JSF came from Sun plus the creators of struts, RegExp stuff from PERL and apache's regexp stuff, java's logging came essentially from Log4j, etc. So really, JEE has essentially absorbed to a greater or lesser extent many of the frameworks/libraries out there as they've tried to be more relevant. I'm glad to see it and I'm glad to see simplification.

Bits and pieces of both, really. Certainly, I'm very keen on using Spring for holding all the pieces together, but I'm happy for all those pieces to be offical standards like JSP/JSF and JPA.

I have been using Java and teaching it at the college level for a decade and I'm tired of it. I still teach it but for all current and future work I'm using Ruby on Rails. Most likely, something better will come along and I will jump to that or retire. Until then I want a fully open-source solution that is light on its feet. RoR is it for now.

I will prefer standards for long run. In my case, it happened many times that support from vendors like JBoss, Sun is much useful than floating in community. Although, I always love to use upcoming ideas from community like Apache.

I have got a feel of JavaEE and it looks nice. I haven't tested thoroughly but, it is definitely better than previous releases.

I will love to see some benchmarking on this part. For small to mid scale projects frameworks are definitely good. They provide quick to the point solution and which is fair enough to go for it. If you want support to legacy systems other plethora of problems then standard based platforms are the best choice.

Glad to see that today there are many options which are worth give a shot!

So the tool vendors claim that the only relevant standards are the ones that they're implementing? How very interesting!

Of course I'd prefer the standards compliant products you listed, if only they were proven in production. In my book, Seam and GlasFish are definitely not. Netbeans 5.5? Last time I checked, Netbeans used to be in IDE. Anyway, it's probably more standards compliant than Eclipse, because it's from Sun. Right?

But how on earth is Spring not standards compliant? Is it somehow incompatible with JDBC, JDO, JPA, JMX, JMS, JSP, JSTL or JavaMail? Or maybe it won't let me use WebSphere, WebLogic, JBoss or GlassFish? Really?

Last not least, Ruby On Rails cannot be taken seriously because it does not adhere to the standards set forth by the Java Community Process. Take that, DHH!

Seriously, as industry thought leaders we should stick with the only production proven and standards compliant solution for now - EJB2!

For the last 7 years I considered using EJB. Every time the artificial overblown complexity turned me off. All our applications had been implemented with simple persistence, using Struts or something similar as the web framework.

This approach worked out very well for me and my collegues.

The whole time I was asking myself, is there anything in EJB that I don't see?

In the end result, to maintain anything in the long run, the code has to simple but no simpler than necessary. This will never be possible with EJB.

The J2EE stack was built with the IBM model in mind. You do not use simple framework, but use layers and layers of indirection. An IBM developer does not write code. The only thing he knows is how to use the tools. IBM is in the business of writing tools, that are so complex without heavy training you can't use them. It is not in their interest to make them easy.

Another example is Eclipse and Websphere Studio developer. Eclipse is very responsive powerfull but simple to use tool, but you need to get a number of plugins to do serious development. Websphere studio is a mammuth, everything is complicated there.

We are talking about 2 different teams here. One is advocating simplicity, the other one complexity.

JSF is a reformulation of Tapestry based on JSP rather than HTML, which imo ruins much of the idea of separating page design/deployment from code. Standards are great, but Enterprise Java is still too complex. Just look at the number of configuration files you need for real world apps.
javax.persistence
javax.servlet
javax.mail (Word API ever)
javax.naming
Tapestry
Hibernate
MINA

I don't really see the need for much else apart from perhaps message queues.

From a lot of the experience that I've seen, JEE standards don't fulfil on that mission to keep things from going obsolete. I've seen multi-million dollar projects emerge time and again for upgrading to each new version of Websphere. And a big portion of that is always reworking based on how the product had to change in response to the standards. I know that in theory if you stick to the letter of the standard in your implementation that you should fare well, but it never seems to work that way in practice.

Is this true: Have others had this problem with standards? When platform changes, lots of work in practice needs to be done to upgrade or else your client's solution goes obsolete.

BTW, Java EE 5 is suppose to be backward compatible to at least J2EE 1.4.

I try to use standard services (JavaMail, JTA, JMS, ...) and standard specialized components model (JSF, JMX, ...) if it's make sense but I don't mind using open source solutions when a specification sucks (web services for instance) or doesn't exist. Also, I believe there is no point about using a standard business object model so in my opinion EJB is going to be a flop again. I rather use Spring to glue the application together.

We use MyFaces-Facelets-Spring-Hibernate-Acegi-DROOLS as a solution stack for our clients, if they are inclined towards Open Source.

I think the confusion in the Java space right now is primarily at the Web Framework tier. There is still a great amount of surface tension when it comes to selecting between Action-Oriented (SAF2) or Component-Oriented (JSF) frameworks; it is not the CHOICES that are confusing the audience, it is the VALIDITY of both approaches that causes it. In reality, JSF should be coupled to a powerful Controller architecture a la SAF2 and then it'd be a pretty smooth ride.

At the database, persistence, messaging, web service tiers - there are established patterns and standards, I don't get the sense that the community seems utterly fractious on those fronts.

Spring is plenty good regardless in terms of being the fridge upon which we throw our magnets on :).

I'm currently learing Enterprsie Facets of Java Such as EJB and Web Services. Seems to me that the complexity isn't really complex at all when you put in some time to learning. I am a fan of Frameworks such as Struts especially the automatic setting of action form bean properties. Those types of helpers are fantastic at times. Lately I've been reading a lot about how J2EE is too complex and there are perhaps better alternatives such as Ruby, which I know nothing about, and perhaps even new cold fusion mx MVC frameworks. I support improvements and helpful frameworks, but to those who complain about the complexity of EJB and that it is hard to learn I say hogwash, turn off the TV and open your books and code code code and code some more before we all end up devalued and replaced by mindless low paid WYSWIG high level markup using drones who wouldn't know a Javabean from a Stringbean.

Complicated? Personally, no. Innovate or die. Why? 'cus we all have to eat. I asked my Math prof/advisor at university what he thought of a profession as a programmer. He said, "Don't do it, they'll have monkey's programming soon, and you'll be out of work." That was more then 10 years ago. He thought that 4GL languages would just get so easy that there would be no need for folks with advanced degrees. Well, it hasn't gotten too "easy" yet. I'm happy for that. I'm still working for a decent rate. Bottom line: I'm not a fan of making software too easy, I like to eat.

I think the complaints about J2EE's complexity are exaggerated by a vocal minority with an agenda to promote. The JDBC/JSP/Servlet levels of J2EE are pretty easy for java/web newcomers to pick up and have been sufficient for a lot application & integration projects I've worked on over the years. EJBs admittedly come with a lot of interface/xml baggage that introduces a learning curve, but this is largely simplified when EJB development is undertaken with the appropriate tools. The EJB sections of J2EE were designed for the enterprise sector with particular scalability & long-term maintenance requirements that benefit from an open specification & framework.

Bear in mind that J2EE came about in the era of DCOM & Corba and was geared towards satisfying the corporate IT environment. Nobody scorned Microsoft's reliance on Visual Studio to generate COM/COM+ components, which hid the auto generation of source & IDL files etc. Trying to develop COM components with notepad would have been considered insane, yet that is exactly the scenario that a lot of J2EE's critics use as an example of how complicated J2EE dev is with 'so many' interface files and xml files to maintain. Try modifying the parameters to a method on a COM component and see how many files need to be manually modified.

So why am I arguing about the recent past? My point is that J2EE (EJBs in particular) was always intended to be undertaken with the help of tools to ease a lot of it's 'complexity'. These days there are a number of free open source IDEs that offer exactly this simplification. In addition, the rise of web 2.0 technologies & techniques (Spring, scripting, RoR etc) has introduced a healthy level of competition that has helped J2EE evolve into it's current version. JEE is now so easy that it is not as unreasonable to tackle a project with notepad as it had been in the past. But with the free/cheap IDEs, why bother? Plus the various JxEE stanards have all been backwards compatable (no?), so I don't see why existing projects need to be 'ported' to newer standards as the evolve. That sounds more like a management issue than a technological issue.

I just don't see this constant Sun-bashing and JEE-bashing as being an accurate reflection of the attitudes of most Java developers I work with. Most of us just want to get on with the job, with good quality tools and standards compliant APIs that will stand the test of time. Poorly specified requirements make up 95% of the complexity of a project, not Java.

Critiquing J2EE/JEE and exploring the benefits of various other solutions has been very beneficial to Java and is always worth pursuing. But lets ease up on the sanctimonious brow beating. I have had enough of the self-elected gurus insisting we hop from 'solution' to 'solution' as if a) previous J2EE code-bases should simply be abandoned and b) there is *really* such as big gain to be had. Somebody may feel they achieve a productivity boost with Spring+Hibernate+This+That wrapped in a Maven overcoat, but good luck finding somebody to maintain that code over 5-10 years when the solution de jour has moved on.

Anyway, enough ranting. Stick to the (backwards compatable)standards, grab an appropriate IDE, keep your designs simple and I fail to see how you can go far wrong.

A brief follow-up...

I also think that J2EE's complexity image-problem largely stems from the navel-gazing indulged by those whose dream up multiple layers of abstraction around J2EE - things like the J2EE blueprints etc. It's not all bad obviously, but I feel attempts to abstract away J2EE behind various strategies/facades are of little practical benefit. If you have commited to J2EE then there is very little practical chance of moving to something else. J2EE *IS* the abstraction layer, don't wrap it up behind even more facades & factories. Just use the APIs in the raw, and it all becomes quite simple.

The End.

For those having problems with migration and backward compatibility, I wonder if you are coding to interfaces and applying abstraction properly. These fundamentals of OOP go a looooonnngggg way toward flexible code that can age gracefully.

My complaint is, why can't I download the J2EE SDK separately. I'm not using the Sun app server, so why make me pick the jars out?

See Random Thoughts at my Blog

Comparing the whole JEE with just webdevelopment is kind of comparing oranges to apples. Lot of people who want their websites developed in little or no time or using rubyonrails and I am not sure about rubyonrails scalability and reliability for enterprise apps.

"Poorly specified requirements make up 95% of the complexity of a project, not Java.", says Mick.

Wow, I don't know where you came up with that percentage, but I sounds about right on, if not letting them off easy. In my experience, it's about 99%.

I see this all the time ... a project is poorly defined/envisioned, and there are no iterations during this stage to refine and perfect the vision. Programmers are asked to start; after the first dev release to the domain execs, massive changes are requested; iterations at the design step is faster than doing it while coding.

Funny thing: RoR and other rapid dev tools ease this problem. You can just allow this bad design trap of waiting until the code is somewhat written to start major redesigns, because redev is fast.

Bottom line: More money for the programmers, because we get to write the same app more than once. Doesn't do much for team moral. Can cause carnage that ends with programmers getting the axe unfairly.

Spring vs JEE just doesn't exist.

Spring provides complementary services to allow simpler implementation of J2EE applications. This simplicity allows for improved maintainability, testability and portability.

Consider the following:
* The framework was introduced in the book "Export J2EE Design and Development"
* This was followed up with the book "J2EE without EJB".

The second book does not say "Without J2EE". It says "Without EJB".

Does anybody feel that EJB 2 is perfect, and that EJB 3 is just wasted time?

If you think EJB 3 is a big improvement and step forward, then you should be grateful to the frameworks such as Spring that have challanged the status quo. Even if you stay with standards compliance you have benefited from their existance. The competition they have provided has meant that the standards have been forced to improve. Isn't that a good thing?

"I think the complaints about J2EE's complexity are exaggerated by a vocal minority with an agenda to promote." - Mick

Why is the complexity of EJB such an issue for some programmers?
http://en.wikipedia.org/wiki/Test_driven_development

A big driving force is test driven development. EJBs just don't sit well with this approach, because of all of their dependancies upon the application server.

Think about the tool you most rely upon. I don't know what it is, perhaps a Gant Chart for a project manager? Now imagine if you were told on your next project that you weren't allowed to use that tool? What would be you reaction?

When you tell a developer who uses extensive automated unit testing to improve the quality of their code that they may no longer use them, they are in the same position.

I have started my second project using JBoss Seam and I love it! Seam+JSF+EJB3 leapfrogs productivity compared to the old J2EE stuff. Dynamic deployment is still a bit of a problem on Java compared to RoR (it's a JVM issue, and not a stack issue), but I've been using unit-testing with Seam+TestNG and it works great.