Skip to main content


Posted by editor on February 11, 2009 at 7:03 AM PST

Guarded optimism for JSR 299

JSR 299 has been undergoing rapid-fire changes in the face of deadlines to get into Java EE 6 (which, as JSR 316, is up for a public review ballot next week). Just last month, it changed names from "Web Beans" to "Java Contexts and Dependency Injection", dropped the notion of being run inside anything other than EE, changed its packaging, and made a bunch of other changes.

It may still be something of a work in progress. Nevertheless, By a 14-0 vote with 2 abstentions, the JCP's SE/EE executive committee has approved it. However, the voting results indicate that several EC members still have some concerns. IBM voted yes with the comment:

IBM has serious reservations about introducing another competing component model into the EE platform when this JSR was supposed to be focused on integrating technologies into the platform. Aside from the duplication and confusion caused by this, the specification has expanded to cover a large spectrum of technology that is somewhat ambitious to fully define within a single specification. However, we acknowledge that the spec lead has made substantial progress in addressing feedback and therefore, we are willing to vote yes to allow the specification to move forward on the assumption that the spec lead will continue to address feedback and concerns.

Oracle and SAP AG both expressed concerns about integration with the rest of EE, with SAP commenting

There are a number of good concepts, but we are missing an overarching principle for a number of diverging goals that this JSR tries to address.

In our opinion, Web Beans would be a great addition to the Java EE platform, in both capabilities and ease-of-use, but only if its ideas are better aligned and integrated into the existing Java EE world.

We have communicated the details of our concerns to the Spec Lead. There is enough goodness that well justifies this JSR to proceed for now and we want to thank the Spec Lead for listening to our concerns.

All said, it's interesting that 299 got approved, rather than sent back for another spec revision. Surely that's a result of the looming vote on EE 6's container JSR. So what do you think? Is it OK to approve JSRs with implicit TODOs, or should the EC only approve JSRs once every "i" is dotted and every "t" crossed? Or are there bigger issues than that?

And finally, are you looking forward to 299, whatever its final name turns out to be?

Also in Java Today,

Java ME developers will be interested in Danny Coward's comprehensive overview, Java ME: Reviewing Mobile Service Architecture 2. "The Mobile Service Architecture 2 (MSA 2) (defined in JSR 249) is the next generation of the Java ME platform for feature phones, following-on from the current MSA 1 (JSR 248) platform (which you can play with here). Given that MSA 2 is about to finish its public review, its time to take a look at it and some of the new APIs that it will add to the platform, so broadly adopted on mobile phones today."

Java deployments are often messy, error-prone, and manual, leading to delays in making software available to users. In Automation for the people: Deployment-automation patterns, Part 2, automation expert Paul Duvall expands on a collection of key patterns for developing a reliable, repeatable, and consistent deployment process capable of generating one-click deployments for Java applications

The recently-released SIP servlet proejct Sailfin 1.0 is the focus of several of today's Weblogs, beginning with Binod's
SailFin V1: Step by step guide to get started. "SailFin V1 is released. This post explains the basic steps by which you can get started with SailFin V1."

Bhavani Shankar continues the Sailfin thread in
SailFin : Develop your own applications using templates. "Writing a new test application in SailFin is made easy using the test templates. End users/developers can easily create & run some some test applications after installing the SailFin server. These test templates can also serve as a tutorial to develop different kinds of SIP servlet applications."

Finally, in Hudson is now a good-behaving Unix daemon, Kohsuke Kawaguchi demonstrates how "Hudson can now behave like a real Unix daemon."

In today's Forums, matormo notes a curious garbage collection behavior in
Young Collections taking longer than Full ones. "I have a high demanding application running under JDK 1.5.0_16, 64bits. The heap is set to 4G for the young and about 10G for the old generation. Survivor ratio is set to 8. Low pauses are more important than throughput for this application, so I'm using the CMS collector. In normal load, young collectios occur each 2 minutes and their pauses range from 500 ms to 1.2 seconds, usally around 0.8 seconds. Full collections take place each hour or hour and a half, with pauses of about 400 ms (just seen a very rare exception of 7 seconds!) Well, my question is, regardless of that 7 seconds pause exception, why I'm having YGC pauses longer than FGC ones?"

Sarah kho wonders
what is status of glassfish v3? "Based on there should be a milestone 2 available for download with almost all features? any news and scheduling to release the m2?"

timz is interested in
Retrieving GlassFish settings in webapp. "Does anybody know if it is possible to retrieve the settings made in Glassfish (like serverName, userName and passWord), so that I can use it in my web app? Iknow it is possible to retrieve values form the persistence.xml file but we have allmost all settings in the GlassFish server."

Finally, midnightjava has a utility for
Choosing JDK or JDIC System Tray implementation at run-time. "I've found it necessary to choose between the JDK and JDIC implementations of system tray functionality at run-time, depending on the version of the JVM in which my code is running. This is because there's a significant bug in the JDIC system tray implementation for Java 6 on Windows (see ), and of course the JDK doesn't have system tray support prior to Java 6. I wrote some code that encapsulates this variability and enables a client to abstractly instantiate a system tray icon and make changes to its popup menu, without dealing with the two underlying implementations. The JDK implementation is chosen for Java 6 or later (for future compatibility), and the JDIC implementation is chosen for versions prior to Java 6."

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.

Guarded optimism for JSR 299