BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Is Java EE 5 lightweight enough?

by Floyd Marinescu on Jul 07, 2006 |
An internetnews article yesterday asked if Java's complexity is its worst enemy. The article started off making the case of Java's complexity and quoted Richard Monson-Haefel (author of the best selling EJB book and Burton Group analyst) saying "They should retire Java EE and work with the open source community to come up with a better solution...The Java solution is so bad people are willing to go their own way and cobble together their own framework to avoid the complexity of Java EE." The article concluded with a quote from another analyst defending Java EE saying that enterprise scale software is complex, and that "Java EE 5 has done a very good job of reducing the level of complexity, but it's still complex, and that's how it's got to be."

Steve Anglin distilled the the problem to a simpler question: "Is the new lightweight Java EE 5 light enough?", and turns the conversation to questioning whether organizations care about standards or alternate light weight frameworks:

...how important are standards to your client’s and/or company’s requirements these days? For example, the Spring Framework and Ruby on Rails may not be considered standards compliant. At least, Sun, JBoss and others don’t think these are, and that Java EE 5 is standards compliant...Standards keep specs and implementations stable, secure, and keeps these from going obsolete... Which [stack] do you prefer?

Steve is inviting people on his blog to comment on their favourite stack, add your thoughts.   Comments so far were that Spring is standards compliant, that standards tend to be driven by tool vendors to sell more product, etc.  Similar discussions were had on the future of enterprise Java panel, and the role of tools vendors in standards definitions also emerged  in a discussion between Craig McClanahan and others in an InfoQ thread about Struts and Shale parting ways.  Accused that JSF's purpose is to drive tools vendors, Craig clarified:
JSF apps can be hand authored just as easily as apps in your favorite action oriented MVC framework. JSF was, *in addition*, designed to make it easy to support with tools. The proof is in the pudding ... besides the existing IDE support for hand authoring JSF apps that is equivalent to what you'll see for frameworks like Struts, you also get to choose from IDEs focused on visual development if you like that approach.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Lightweight? by Billy Newport

Depends what you mean. Are application servers going to have a smaller footprint, no, the APIs are just a veneer on top of the code thats already there, it's basically the same code under a JavaEE 5 server except now they need to support the older standards and a new one, it's not going to get smaller. From a developer point of view is there less XML to tweak yep. Besides the XML I don't see a whole lot of difference for the developer given tooling had advanced to make the extra interface classes etc basically invisible.

They really need to develop parts of the spec completely independantly and make them usuable without a container JPA is a good step in that direction. We're starting down that path also with things like caching/ObjectGrid.

infrastructure vs. apis by Floyd Marinescu

My own opinion on the matter is that things like developer-facing API/frameworks are becoming less necessary for standards bodies as opposed to infrastructural components consumed by all vendors (open source included) in the space, such as the notion of the Servlet and HTTPSession, JTA, JMS, annotations, the JVM specification, etc. These infrastructural standards bring consistency in offerings across all Java projects. Perhaps the approach should be standardize the plumbing, compete on the domain specific frameworks.

It's interesting how when it comes to SE, nobody complains if the class library is bloated (a big class library is one of the reasons Java succeeded), but in EE there is so much controversy.

different strategies for different times? by Floyd Marinescu

They really need to develop parts of the spec completely independantly and make them usuable without a container JPA is a good step in that direction.

Interestingly, the fact that J2EE as a platform was defined as a big umbrella spec was very important and very successful back in 1999-2000. It's what the industry needed in order to migrate away from the 30+ vendors specific platform programming models and to a standard.

However, today, your plug and play approach sounds a lot more compelling. A number of application servers have already adopted modular architectures to enable similar capabilities.

Re: infrastructure vs. apis by Alexandre Poitras

My own opinion on the matter is that things like developer-facing API/frameworks are becoming less necessary for standards bodies as opposed to infrastructural components consumed by all vendors (open source included) in the space, such as the notion of the Servlet and HTTPSession, JTA, JMS, annotations, the JVM specification, etc. These infrastructural standards bring consistency in offerings across all Java projects. Perhaps the approach should be standardize the plumbing, compete on the domain specific frameworks


I complety agree with you on this one. Standardize the infrastructure services but not how to access them and how to structure your application. In my opinion, the different frameworks or component model shouldn't be standardized (except maybe JMX) since this is where most of the innovation is taking place. There isn't any component model in JSE and I think it's great so why JEE should be different?

J2EE encourages way too much developer to structure their code according to the type of component they are creating. At least, JEE 5 is going the POJO way but I still don't like the EJB3 specification. Why would I need a business component model? I want to be free to add whatever services I need to my objects like JPA or even homegrown ones. Spring seems to have proven that this strategy is very effective. Well, I know I am going to take a serious look at JPA but I don't think I'll use EJB3 session beans.

Re: infrastructure vs. apis by Billy Newport

Thats the problem, developers already had injection, POJO based programming with IoC frameworks and the web frameworks. As for tools, I don't think anybody makes money in J2EE tooling anymore. Eclipse is just too good.

Non invasive middleware is the way to go.

Re: Lightweight? by Jason Carreira

Depends what you mean. Are application servers going to have a smaller footprint, no, the APIs are just a veneer on top of the code thats already there, it's basically the same code under a JavaEE 5 server except now they need to support the older standards and a new one, it's not going to get smaller. From a developer point of view is there less XML to tweak yep. Besides the XML I don't see a whole lot of difference for the developer given tooling had advanced to make the extra interface classes etc basically invisible.


If you and other vendors can't make things lighter, you're destined to continue to lose out to Tomcat/Resin + Spring + whatever else I need that I specifically wire in.

WebSphere needs to take more ideas from Geronimo and let individual pieces be brought in without the rest of the stack. If I just want the JTA TX manager, JMS, and the servlet container, let me configure the stack that way. Let me make the container profile exactly as much as I need, and no more.

Re: infrastructure vs. apis by Frank Bolander

Billy,

Are you thinking along the lines of AOP style middleware where various aspects encapsulate services and are composited onto an application? Or are you talking about strict DI/IOC stuff.

Although DI/IOC has definitely helped with the development lifecycle, I think "lightweight" for the sake of lightweight is dangerous. Appservers provide multitudes of services and features that unfortunately have required explicit hooks to utilize. Let's not forget that we still need getters/setters to hook into "transparent lightweight frameworks". I'm not sure why this is considered lightweight compared to implementing container interfaces. Plus I think the whole "JEE is too complex" is way overblown to justify some group's or person's "lightweight framework" or agile methodology. Yes, there were mistakes along the way, but there also has been great progress which for the most part has been flippantly disregarded because of "poet architect" egos.

I think JEE is moving in the right direction after these past several years of inertia.

Re: infrastructure vs. apis by Mike Keith


I complety agree with you on this one. Standardize the infrastructure services but not how to access them and how to structure your application. In my opinion, the different frameworks or component model shouldn't be standardized (except maybe JMX) since this is where most of the innovation is taking place. There isn't any component model in JSE and I think it's great so why JEE should be different?

Writing applications in the enterprise is a different ball o'wax from writing a simple client program. An enterprise application requires additional technologies and services that suit it for scalable client access. These services (plumbing) should be reusable and pluggable so that they fit together and can be swapped (like JPA). We are not there yet in Java EE 5, but hopefully once people see the JPA benefits they will demand the same for other Java EE components. The interfacing of these technologies needs to be standarized both for this pluggability and for application portability from one app server to another.

J2EE encourages way too much developer to structure their code according to the type of component they are creating. At least, JEE 5 is going the POJO way but I still don't like the EJB3 specification. Why would I need a business component model? I want to be free to add whatever services I need to my objects like JPA or even homegrown ones. Spring seems to have proven that this strategy is very effective. Well, I know I am going to take a serious look at JPA but I don't think I'll use EJB3 session beans.

Every application should have a "business component model", whether it is EJB or just plain JavaBeans. It is just plain good software design. You don't need to use the Java EE prescribed model if you don't want to, but the benefits of doing so are endless, e.g. portability, shared terminology set and communication patterns, training, skills reuse, and the list goes on.

If the components were pluggable then you wouldn't need to even require the unused components to be in the server (unused as they might be). The problem right now is that people are forced to at least open and look at the whole Java EE pie, even if they don't have to actually eat it all.

Re: infrastructure vs. apis by Alexandre Poitras


I complety agree with you on this one. Standardize the infrastructure services but not how to access them and how to structure your application. In my opinion, the different frameworks or component model shouldn't be standardized (except maybe JMX) since this is where most of the innovation is taking place. There isn't any component model in JSE and I think it's great so why JEE should be different?

Writing applications in the enterprise is a different ball o'wax from writing a simple client program. An enterprise application requires additional technologies and services that suit it for scalable client access. These services (plumbing) should be reusable and pluggable so that they fit together and can be swapped (like JPA). We are not there yet in Java EE 5, but hopefully once people see the JPA benefits they will demand the same for other Java EE components. The interfacing of these technologies needs to be standarized both for this pluggability and for application portability from one app server to another.

J2EE encourages way too much developer to structure their code according to the type of component they are creating. At least, JEE 5 is going the POJO way but I still don't like the EJB3 specification. Why would I need a business component model? I want to be free to add whatever services I need to my objects like JPA or even homegrown ones. Spring seems to have proven that this strategy is very effective. Well, I know I am going to take a serious look at JPA but I don't think I'll use EJB3 session beans.

Every application should have a "business component model", whether it is EJB or just plain JavaBeans. It is just plain good software design. You don't need to use the Java EE prescribed model if you don't want to, but the benefits of doing so are endless, e.g. portability, shared terminology set and communication patterns, training, skills reuse, and the list goes on.


There are only 2 things I ask of my JEE container :
1) Standard APIs (JMS, JTA, ...).
2) Standard ways to expose my components to a given protocol (Servlets, JMX, remote EJB)

On the other hand, I don't want to be forced to use any business component model except JavaBean of course. I can get all the other services a EJB provides me quite easily without resorting to an heavyweigth container :

1) A good IoC container allows me to lookup intra-application dependencies
2) A good IoC container allows me to manage my objects lifecycle.
3) Handling cross cutting concerns is way easier using a good AOP tool. Plus, I can use whatever APIs I want (homegrown, commercial, open source, ...). I don't have to deal with all the "standards" if I don't need to and I can "weave in" any product I want to use.
4) Stateful objects. State is a concept strongly associated to the remote model you use and I think it should be handled by a thin remote layer (like servlets) so I prefer using staless objects at the moment. Altough, JBOSS Seam seems quite interesting and I may be wrong in this case.

It's true that EJB3 has a lot in common with those solutions (but it's still less powerful IMO) and is way more elegant than EJB2. But the main problem is still there : the specification doesn't force the container to be embeddable and that's a HUGE turnoff (at least JBoss EJB3 supports it). So I would still have to go througth this painful compile-deploy-test cycle again and this is a no go if you use TDD.

And I don't buy the advantage of a standard in term of portability : Portability is important when the product isn't packaged with your application (for instance JTA) and runs independently on the server. But if you take the example of a lightweight container like Spring or a persistance framework like Hibernate, it is always bundled with your application so portability isn't really an issue there. As for skills, training, common vocabulary, there are tons of good books and training on any popular open source solutions.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

9 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT