Skip to main content

The Perils of Pruning Established Technologies (Java EE 6)

Posted by editor on April 8, 2009 at 7:15 AM PDT

Successful technologies have a natural tendency toward feature bloat over time. This makes sense, because once a technology becomes widely used, the user community--a varied lot--submits requests for enhancements. The development team naturally wants to respond to the community's needs, and new features are integrated into future releases of the technology. Unfortunately, this can ultimately lead to the technology becoming so feature rich that it becomes formidable for new users to embrace it.

Today's Java Today lead article, by Charles Humble, talks about the pruning that is planned for the upcoming Java EE 6. You can see all the details in JSR 316. Charles points out that the current Java EE appears complex and intimidating to new developers:

new developers looking at the the platform don't always realise that it is as well suited for developing simple systems, such as basic CRUD web applications, as it is for building much more complex ones.

JSR 316 admits that "the reach of the Java EE platform has become so broad that it has lost some of its original focus." To address this, the development of Java EE profiles is proposed. These profiles will consist of Java EE editions that target a specific platform or purpose. The first such profile will be the Java EE Web profile, which Roberto Chinnici outlined in his Java EE 6 Platform Public Review post in January.

The addition of profiles will bring to Java EE one of the advantages that has contributed to the success of Linux: a stable core technology that is available in multiple, differentiated packages. Users then would not say "I'm going to use Java EE"; rather, the decision would become "which Java EE profile is most suitable for my needs?" There appears to be widespread agreement with Rod Johnson's statement from last summer that the "one size fits all model" is less and less appropriate.

Profiles are a great idea. But pruning is always difficult. Even if relatively few developers are using the to-be-pruned features, when features are pruned, it puts those developers into a bind: upgrading to the new platform will break their applications! Yet, if they don't upgrade, then their application will be at a competitive disadvantage, because it will no longer embody the state of the art underlying core technology. It is for this reason that many technologies adopt the deprecation approach, where features that are considered prunable remain available within the base technology for years, but developers are advised to steer clear of these implementations and apply their more up-to-date equivalents.

These difficulties may be part of the reason why Java EE 6 has experienced such a curious history thus far. Chris Adamson talked about the surprising events that occurred last year between April and July with the Java EE proposal: "Scratch JSR-313... EE 6 lives on as JSR-316." A poll on JSR-316 found that, among participants who were interested in the JSR, most liked it; but the largest plurality of voters had no intention to read the JSR, and quite a lot of people who planned to read it hadn't yet done so.

Even the JSR-316 Public Review Ballot didn't show the unity you'd like to see in a major technology specification: while major participants like Sun, HP, IBM, Intel, and Oracle voted "yes," Apache voted "no," SpringSource abstained, and Eclipse and Nortel did not vote. So, there were 12 "yes" votes. That's 75%, but still...

The history of Java EE 6 is indeed interesting. A valiant attempt is underway to mold and massage the technology into being a more viable competitor going forward. The development work to accomplish that will be substantial, just as the decision-making on what to prune and how to package the next Java EE has at times been a procession of fits and starts.

The latest Java Mobility Podcast is
Java Mobility Podcast 75: Daniel Green on kids and computers, in which Daniel Green from Sun Microsystems talks about computers in education, getting kids excited, and computer clubs on thumb drives.

In Java Today, Charles Humble writes about Pruning The Deadwood from Java EE: "A key reason for the success of the Java EE platform is its breadth of coverage, however the number of APIs and technologies that make up the specification also create issues for both developers and vendors wishing to adopt it. For new vendors wanting to build a Java EE application server, the complete specification represents a substantial barrier to entry reducing competition in the space. For new developers coming to Java EE, the vast numbers of APIs and acronyms can be intimidating."

Rick Hightower published An Introduction to Spring AOP: "This article discusses Spring AOP in a tutorial format. It covers some of the newer features of Spring AOP like annotations, improved XML configuration and more. It builds on the DIIntroTutorial. It is meant as a simple introduction to AOP. Enough information so you ?can use AOP on a project."

And Danny Coward reports about the upcoming release of JavaFX in JavaFX: Faster, faster!: "One of the things the href="">JavaFX
team is working at for the next release is graphics and video performance, and, is doing so in the light of experience from app developers with the technology. Like book author Jim Connors, who today posts an interesting look at ways to keep an interesting design, but with fewer items in the scene graph to make it. Or in other words, href="">how many nodes does it take to make a clock."

In today's Weblogs, Arun Gupta provides a new lesson of the day, LOTD #19: Securing GlassFish Installation: "Found great (old) blogs (part 1, part 2) by Masoud Kalali that discusses the different ways to secure a GlassFish installation. Changing master password and admin console passwords (both web-based and CLI) are two fairly trivial operations..."

In Much A-do About Nothing, Cay Horstmann writes about a dilemma relating to loops: "I describe my dilemma about the proper treatment of the do-while loop in an introductory computer science textbook. I want to position it as an advanced/optional topic, but reviewers want to give it equal billing with the while and for loop, even though it is rarely used (about 2% in the JDK library source)."

And Manfred Riem talks about EJB Almanac @ActivationConfigProperty: "How do you filter what messages are to be consumed by a message driven bean? There comes a time you want to split the stream of messages to particular message beans. This annotation can be a handy thing to accomplish that..."

The current Poll, which will end on Friday, asks "Are you more likely to use a library or framework if it comes bundled for your IDE or build tool?"

This week's Spotlight is about the upcoming Community Corner Podcasts at JavaOne.

In today's Forums, Doub Twilleager responds to a query about Re: WL 5 Dev 3 "Pick" issues: "How are you sending this to Wonderland? Who calls createSceneGraph()? There are many systems that are built around jME to support all of the Wonderland features. Because of this, vanilla jME code needs to be put into the system in very specific ways. Here are a couple of examples: - Lights: jME has a very restrictive way of propagating light state in the graph, so we have a layer on top of jME to deal with lights."

greg80303 has questions about Executing java/javac build commands under Cygwin: "I am building phoneME Advanced CDC PBP on Win32 XP using Cygwin and cross-compiling to MinGW. Cygwin "make" does not support the use of windows-style pathnames. It does not like the ":" character found in windows pathnames and it confuses it with the ":" that separates targets from prerequisites. The error usually manifests itself when a makefile includes the GCC-generated dependency files (.d) and you will see something like this: obj/romjava0.d:1: *** multiple target patterns. Stop."

And Chen Fishbein responds to the query Re: Memory leak? Some profiler analysis: "Hi, The Dimensions and the Rectangles you see are basically the dirty areas on the screen that the ui needs to refresh, therefore they change all the time. Most application don't have a running thread that keeps changing the ui all the time, and if nothing is changed the UI thread is in a wait mode causing no harm to the memory. I agree there is room for improvement here, but you shouldn't get too concerned from this, please open an RFE on that matter."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

Successful technologies have a natural tendency toward feature bloat over time...

Related Topics >>