Javalobby - Comments for "Why are we not using Java EE 5?"

In response to Antonio's

pyrosvallum — Tue, 25 Mar 2008 12:40:57 -0400

In response to Antonio's last post:

"It might sound strange to ear (because we've been saying the opposite for long time), but Java EE 5 applications (JSF/EJB3/JPA) are easier to write than a Struts/Spring/Hibernate one. And because we are talking about standards, tools are getting really powerful."

That is so true. I wrote a media rental system for a local business in 15 hours (approx). I used NetBeans, MySQL, and Glassfish with some JSF (which is great by the way - read the JSF chapter in Apress' Beginning Java EE5 - it's brilliant!). Am I a noobie? Hell no! I used to teach the FJ310 course for Sun Microsystems UK about 4 years ago. J2EE 1.4 was absolutely hopeless, so many xml files, empty boiler-plated methods and DDs to make you puke with depression. And don't get me started with the Remote/Home Interfaces. Argh!

But with Java EE 5, I was asking myself "Is that it? Is that all I need? @EJB? @Stateless? Wow. So I'm hooked.
the latest Sun course teaches you how to do it.

At the moment, I'm working with a company who have got this JavaScript/Spring/Hibernate/extJS/JSON/DAOs/DTO/spring.xml/ORM/literal-embedded-object obession going on which is driving me mad! It's like they're actively avoiding everything Java EE 5. It's just irritating - so many freakin' layers! I've created a dialog in ExtJS which has taken a week! A WEEK! Weaving everything together to make a multilayered mess! I could have written this dialog in Swing in 5 minutes!

Java EE 5 rocks.

One reason for the the slow

pm66920 — Sat, 08 Mar 2008 16:10:53 -0500

One reason for the the slow take up is that development managers are a lot more weary now about using application servers (or anything else for that matter) that are not battle tested..... and of course, the pull great alternatives like the Spring framework.

Quote:@svadu: GlassFish is

svadu — Mon, 11 Feb 2008 18:21:33 -0500

Quote:

@svadu: GlassFish is not your father's reference Implementation. Just give it at try. You might be surprised by the management tools, the clustering or the performance. Some early success stories starting to show up here: http://blogs.sun.com/stories

I am not talking about myself I meant it in general that it may not be adopted as fast as it deserves just because of the bad name of the previous reference implementation (a situation similar to J2EE - JEE5 btw). As for me I've made my choice...

Very good article.I only

nm48081 — Thu, 31 Jan 2008 05:52:11 -0500

Very good article.

I only hope that teacher in University did the switch to JEE 5. A beginner should learn directly JEE 5 and that's it.

I checked this morning in a Technical Training Company that works with us: there's still some training about "J2EE 1.4 with EJB2.1". Believe it or not, some people still makes a lot of money on top of this poor J2EE 1.4... Let him rest in peace

Nic

-----------------------------------

http://www.touilleur-express.fr

A number of well-taken

davidsills — Wed, 30 Jan 2008 20:38:08 -0500

A number of well-taken points. I have to admit I'm only now getting 'round to EJB3, which seems amazing to me after EJB2. Even Spring, which I've taken to, has things to learn from it (and they are doing so, as noted above).

I still like Spring just fine and I'll continue to use whatever I think best serves my clients - my usual concern has changed from not wanting to be too far behind with technology to wanting to leave my clients with something they can really maintain. The move in the Java EE space from XML to annotations: good. The move from JSP (enough like classic ASP that even M$ies can follow it) to facelets: not so much. Not that there's anything wrong with the technology: on the contrary, I like the idea. But there's an awful lot of magic, which tends over time in my experience to be hard to maintain. Not to start a flame war: if I had the right client I'd take up facelets in a second.

But for me Java EE 5 is a step in the right direction, and the fact that Oracle AS took it up early and reasonably well is a big plus for it (again, to my clients). Not that there aren't still teething problems, but that's true of everything (note the RMI issues mentioned above!).

I'm keeping my mind open about everything until the landscape clarifies itself and keeping up with Java EE 5 and with Spring (and watching Seam and Wicket and ...).

David

@svadu: GlassFish is not

alexismp — Wed, 30 Jan 2008 16:15:33 -0500

There is an interesting

agoncal — Wed, 30 Jan 2008 16:11:14 -0500

There is an interesting thing happening at the moment though. We all know that Java EE 5 got its inspiration from open source software like Spring/Hibernate. But today, things are changing. Spring 2.5 is getting its inspiration from Java EE 5 (less XML and more annotations), Seam is working hand in hand with Java EE (Seam will be WebBeans in Java EE 6).

Using Spring over J2EE 1.4 was like a breath of fresh air. But today, when I look at a Struts/Spring/Hibernate application vs Java EE 5, I don't understand such complexity :verbose ioc, low level mvc framework, xml wiring, xml orm mapping, struts-config.xml, more xml, HowLongYouWantMeToTypeMySpringClassName (I forgot Abstract in the sentence)...

J2EE 1.4 left us with bad legacy design and patterns. When we say that Java EE is complicated, it's not just because of the amount of specifications. Our architectures need such complexity, so we need a specification to answer this complexity : we were not doing Web Services 5 years ago, now we are, so we need a spec; Java EE 6 will introduce a Resftul specification, because that's what we are starting to do.

What made J2EE 1.4 complex was also the all Pattern thing (DTOs everywhere, DAOs, Delegate, UniqueIdGenerator, ServiceLocator...). Now I still see plenty of Java EE 5 projects using the same patterns. That's why people say Java EE 5 is difficult. It's because we got used to a certain type of architecture (Entity Beans were not serializable, that's why we used DTOs), and we have to rethink that today (it's not that bad to use a JPA bean on the client side if needed). When you see an application with domain objects, DAOs, ORM mapping, Spring services, XML wiring, DTos, Struts form, struts-config, Struts actions and JSPs... god, how much more complexity can we handle.

It might sound strange to ear (because we've been saying the opposite for long time), but Java EE 5 applications (JSF/EJB3/JPA) are easier to write than a Struts/Spring/Hibernate one. And because we are talking about standards, tools are getting really powerful.

@tonetheman

I can bang out a web app with JPA/EJB 3.0 in NetBeans and deploy it in GlassFish (without writing any XML) and you still be wiring your Spring beans ;o)

I must admit, I was

sdnakhla — Wed, 30 Jan 2008 09:56:48 -0500

I must admit, I was travelling down the Spring/Hibernate path. Spring is a great framework that makes it easy to get rolling with large-scale enterprise applications. After working with it for a while, I wanted no part of Java EE. However, I recently started playing with the Seam framework from JBoss, and love it. To me, it feels like Spring for Java EE. The use of annotations eliminates most of the need for XML descriptor files. Plus, it integrates well with Spring, Hibernate, and tons of other libraries. In developing JSF-based applications, I've found it to be far more functional and provide a much quicker development cycle than the Spring/Hibernate combination alone.

There is no question in my

tonetheman — Wed, 30 Jan 2008 08:19:28 -0500

There is no question in my mind... Java EE is a bloated piece of shit. Anyone who tells you otherwise has not had the pleasure of working with other toolkits. It started out long ago as a large turd and through each revision the turd has been shined... but it is still a turd.

You and I could start writing a web app at the same time... and you would be on 3rd or 4th xml description file when I was finished already.

The reason why other toolkits have taken off and left the turd behind are usefulness. It is plain and simple.

I've to smile a bit reading

rainwebs — Wed, 30 Jan 2008 07:51:46 -0500

I've to smile a bit reading such an article these days. Sorry, I'm working with Spring for some time, had a short look at EJB3, and have problems to follow such a perception. It looks like you try to conserve what the market already defines as legacy:

http://blog.springsource.com/main/2008/01/23/spring-overtakes-ejb-as-a-skills-requirement/

I understand that you still try to follow the official standards. I did this in the past, too. But, some thoughts about standards from a former Sun Java Architect:

http://blog.rainer.eschen.name/2006/11/15/successful-software-architects-ignore-standards/

BTW: The platform for Spring will be Tomcat ;-):

http://blog.springsource.com/main/2008/01/29/some-decisions-are-easy-%e2%80%93-like-springsource-acquiring-covalent/

Which projects really need an EJB container these days, besides those that have to integrate EJB 2.1 legacy applications or use the connector architecture anyway?

I had a deeper look at JSF OpenSource implementations and can't share the enthusiasm for this official standard:

http://blog.rainer.eschen.name/2007/05/15/flash-or-pure-web-programming-to-skip-jsf-or-struts/

Sure, JSF is comparable to what I did during my desktop development projects in comparison to Struts. But it's overstated complexity delivers error-prone frameworks. The maintenance of code we develop in this context will be more expensive than with Struts legacy of these days. Have a look at what code quality you get in the browser page sources if you don't believe this. Combinations with AJAX are even worser.

Maybe it's a better idea to keep Struts and change to "Flex on Spring" in the next years:

http://blog.rainer.eschen.name/2008/01/29/web-killer-apps-on-the-horizon-flex-gets-mainstream/

Nice comparison. There

farzad — Tue, 29 Jan 2008 21:51:02 -0500

Nice comparison. There reason I am still stuck with an older version of Java EE is that we have a product which has been developed with older versions of Java EE and they can still sell it. Unfortunately, the product has used Entity Beans to its extereme, but my understanding of North American business model is that we don't need to change it if we can still sell it. At the same time we have customers which are with an older version of WebSphere (5.1) and we can't just force them to buy an upgrade. Believe it or not, my IDE can do crazy debugging things but it keeps disconnecting from application servers because of annoying jvm bugs in version 1.4. The other thing that is bothering me is that I can't even use ehcache, and similar frameworks, without doing crazy modification because RMI implementation has a bug in version 1.4 and this list continues. I do face a lot of resitance from management when I plan to move to a newer version.

As for Spring vs Java EE, I do not agree Spring is a replacement in many cases since spring has been designed to be lightweight, even though it does a lot of heavy weight lifting these days, and there are still services spring does not offer. I do like a mix of EJBs and Spring. Spring is very useful for a business logic sort of container.

Farzad-

@agoncal:1. You usually use

ronaldtm — Tue, 29 Jan 2008 21:33:58 -0500

@agoncal:

1. You usually use Hibernate, not JPA, unless your application is really simple. This is because the JPA spec doesn't include many optimizations (cache, for example), which were left for implementor-specific extensions. Also, in many cases you use implementation-specific syntax in EJBQL (or just plain old HQL) without even noticing.

2. Java EE is not EJB! Tomcat is not full Java EE compliant, but it does implement a subset Java EE, and an application that runs on Tomcat IS a Java EE application. I mean, an application doesn't need to use EJB to be considered Java EE, am I right? (I know that Java EE is more than EJB + what Tomcat provides, but most developers don't, or don't really care)

@svadu:

Spring doesn't prohibit you from use EJB, but since the former provides almost all services of the latter, in a much cleaner and simple way, it basically makes EJB unnecessary. Many see JBoss as a Tomcat with EJB support, so, if you don't use EJBs, Tomcat is just fine, and you don't need JBoss. So, Spring IS a threat to JBoss, at least in the low-end and 'free-as-free-beer' market.

drobert_bfm wrote:I used to

svadu — Tue, 29 Jan 2008 19:22:59 -0500

drobert_bfm wrote:

I used to believe that IBM had big plans for Geronimo. I now think that they were just trying to kill JBoss. They really shouldn't have: JBoss is facing far more considerable foes: Glassfish on the JEE side, and Spring on the "everything else" side...

Well, I think many people still don't trust the reference implementaions so I am not sure if it's really a menace from Glassfish here, at least not until there will be some high volume public sites that are based on one (otherwise it will be just a reference implementation and a 'free' server implementation for communities). It requires quite heavy PR to be seriosly considered by enterprises.

Spring on the other hand doesn't even has its own runtime (at least not yet) I don't see how a framework can be a menace to JBoss? :)

I tend to agree with the

svadu — Tue, 29 Jan 2008 19:16:41 -0500

I tend to agree with the article on some points.

First, there is a 'reputation' of J2EE 1.4 - people switched to lightweight frameworks.

Then JEE 5 came out and looks like many people simple didn't bother due the big delta between 1.4 and 5. While there seem to be huge difference actually there is not, except that you shouldn't compare with J2EE 1.4 but with those lightweight frameworks (Spring+Hibernate+Axis, etc).

It's not the frameworks that implemented the JEE 5 spec, it's the spec that got 'adapted' to the frameworks.

Don't forget, there is direct influence of Struts and Hibernate creators on the JEE 5 spec and Spring influenced it as well. So, big difference? No, just need to re-think what you compare to :)

Sorry, but that's simply

drobert_bfm — Tue, 29 Jan 2008 18:43:55 -0500

Sorry, but that's simply not true. Websphere *Community Edition* is geronimo plus a few cosmetic changes, but Websphere Application Server has nothing to do with geronimo. There are quite a few rumours out there that WebSphere 7, if it ever comes out, might be based on Geronimo, but considering the work IBM put into building 6.1 on top of OSGi, I'm now skeptical of even that.