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:
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.
Community comments
Lightweight?
by Billy Newport,
different strategies for different times?
by Floyd Marinescu,
Re: Lightweight?
by Jason Carreira,
infrastructure vs. apis
by Floyd Marinescu,
Re: infrastructure vs. apis
by Billy Newport,
Re: infrastructure vs. apis
by Frank Bolander,
Re: infrastructure vs. apis
by Mike Keith,
Lightweight?
by Billy Newport,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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 Billy Newport,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
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.