BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon New York

Find real-world practical inspiration from the world’s most innovative software leaders. Attend in-person.
QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or get video-only pass to recordings.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News Is Java EE 5 lightweight enough?

QCon New York (June 13-15): Learn best practices from senior developers at early adopter companies.

Is Java EE 5 lightweight enough?

Bookmarks

Jul 07, 2006 2 min read

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more
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.

Rate this Article

Adoption
Style

This content is in the Java topic

Related Topics:

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.

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

Community comments

  • 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.

    Back to top
  • 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.

    Back to top
  • different strategies for different times?

    by Floyd Marinescu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

    Back to top
  • 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.

    Back to top
  • Re: Lightweight?

    by Jason Carreira,

    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.


    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.

    Back to top
  • 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.

    Back to top
  • Re: infrastructure vs. apis

    by Mike Keith,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    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.

    Back to top

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

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

BT