JavaOne has a catalyzing effect on Java developers: their enthusiasm and energies spike around the show; they ready their latest and greatest Java technology-based projects and solutions for the annual encounter with software programmers from around the world. Take for instance the JSR Spec Leads - they too intensify their efforts around the show to submit new JSRs to the program, advance work under development to the next stages, or finalize standards. JavaOne is a favorite event with JSR Spec Leads who don't miss on the opportunity to leverage the Conference as an ideal forum for sharing their accomplishments and forays into new Java standards projects with their fellow developers. The show's 2006 edition was no exception. Here are the JSRs that brought the JCP Program closer and closer to the 300 mark and crossed it in less than a month.

Modularity in Java is tackled by JSR 294, Improved Modularity Support in the Java Programming Language, led by Gilad Bracha, Sun Microsystems. The project sets out to extend the Java programming language with new constructs that allow hierarchical modular organization. The Spec Lead and Expert Group expect these constructs to be supported at the virtual machine level, through modifications or extensions to the JVM's access control rules. If you are interested in modularity in Java, check out the JSR page, contact the Spec Lead for more information, or send your comments to [email protected]

Another JSR submitted around the same time is JSR 295, Bean Binding. It aims to define an API that greatly simplifies connecting a pair of JavaBean properties to keep them in sync. As proposed by the Spec Lead, Scott Violet of Sun, the connection is intended to be configurable with type conversion and validation operations being able to be applied before updating a property. Bean Binding will be developed so that it reduces the amount of tedious and error-prone code JavaBean developers must write by making additions to the JavaBeans API that up-level connecting pairs of JavaBean properties.

The May marathon of new JSR proposals continued with JSR 296, Swing Application Framework introduced by Sun with Spec Lead Hans Muller at the helm. This JSR commits to providing a simple application framework for Swing applications. It will define infrastructure common to most desktop applications. In so doing, Swing applications will be easier to create. The experts working on it anticipate supporting implementations for current Java releases as well as Java SE 7 (code name "Dolphin").

The next JSR submitted at the time of JavaOne is JSR 297, Mobile 3D Graphics API 2.0, and is targeted at Java ME. It was introduced by Nokia and is shepherded by Spec Lead Tomi Aarnio. The specification is a new revision of M3G (JSR-184), which plans to expose the latest graphics hardware features on high-end devices while improving performance and memory usage on the low end. The submission of this JSR was prompted by the needs of developers, device vendors, operators, and consumers who are looking for richer, smoother, more realistic graphics for games and user interfaces, as the JSR page highlights that I recommend you visit if you're interested in keeping abreast of the latest in the area of Mobile 3D Graphics.

A relatively new member of the JCP, SK Telecom Co. has already embarked on developing a JSR for telematics, JSR 298, Telematics API for Java ME. The proposal, currently under reconsideration ballot, sets out to define the API set for Telematics Service on mobile devices. A Java-based telematics standard could facilitate the introduction of new value-add services related to car management ranging from 911 emergency calling to complex driving guidance. SK Telecom believes that by providing a uniform API set designed for embedded devices, the existing telematics solutions and services can be modified in a more interoperable way and a variety of new Java-based telematics services will emerge more easily. If you are into telematics or aspire to enter this field, check out the JSR page and send your comments to [email protected]

An active participant of the JCP, JBoss came forward around the same time with a project that became JSR 299, Web Beans API. The Spec Lead is Gavin King, a seasoned lead and expert group participant, who will drive the development of the specification to accomplish a standard that unifies the JSF managed-bean component model with the EJB component model. The result of this work is hoped to be a significantly simplified programming model for Web-based applications. The specification promises at the end of the standardization work to provide a programming model suitable for rapid development of simple data-driven applications without sacrificing the full power of the Java EE 5 platform. If you've been following the evolution of the EJB and persistence standards, make sure you check out this proposal too.

The JSR sprint continued after JavaOne. LG Electronics submitted DRM API for Java ME shortly after the conference and with it the first JSR in "the 300 series." Dnyanesh R. Pathak, the JSR Spec Lead and the supporting Expert Group, will work to define an optional package for developing Java ME applications that utilize or interoperate with DRM agents that separately exist in devices. The proposed JSR commits to providing standardized support for digital content protection and management of the rights by enabling APIs to interact with the underlying DRM agent(s). Developers will be able to use this JSR for interacting with the DRM agents for developing applications that handle DRM-protected content.

JSR 301, Portlet Bridge Specification for JavaServer Faces from Oracle followed in July, showing that there's no let up when it comes to Java developers' enthusiasm and dedication to Java technology even if it comes head-to-head with heat waves or tempting vacation plans. Michael Freedman will lead this project, which attempts to standardize the behavior of bridge implementations to ensure true interoperability for JavaServer Faces artifacts. At the time of writing the JCP Executive Committee (EC) still have to vote this submission as a JSR, but once it's approved, if you want to participate in its development I encourage you to contact the spec lead.

The JSR EC ballot of July 24 will carry two more interesting proposals. One is JSR 302, Safety Critical Java Technology from The Open Group to be led by Douglass Locke. The project proposes to create a Java ME capability, based on the Real-Time Specification for Java (JSR-1). The proponents argue that safety-critical systems need a certifiable (e.g., DO-178B) Java environment. Certifiability implies hard real-time resource management and generally very small implementations with low complexity. The existing Java ME and RTSJ (JSR-1) specifications contain too many and too complex functions to render them certifiable. For example, Java ME and the RTSJ assume the presence of a garbage collector; the proposed specification will not assume the presence of a garbage collector.

The other project on the ballot is JSR 303, Bean Validation. The specification intends to define a metadata model and API for JavaBean validation and will not be specific to any one tier or programming model. The Spec Lead, Jason Carreira, views this API as a general extension to the JavaBeans object model and as such expects it to be used as a core component in other specifications, such as JavaServer Faces, Java Persistence API, and Bean Binding. This standardized validation metadata and standard validation API will be valuable across a number of application domains, from Swing desktop applications to Web applications and the persistence layer. The intention is also to deliver this JSR as a component of Java SE 7 (code name "Dolphin") and develop an implementation of the spec as a public open source project, either at java.net community or the Apache Software Foundation.

As I'm signing off, I'm doing a final check of JSR submissions and, yes, a new proposal has just come in, this time a Java ME project from Motorola and Ben Q Corporation, JSR 304, Mobile Telephony API version 2. The proponents plan to take this specification beyond JSR 253 (Mobile Telephony API) and include support for some technologies such as VoIP. They also intend to address some aspects related to control of video telephony sessions.

Forget the summer blues, Java developers keep cool projects coming - 11 new proposals in just a few weeks - which merit keeping an eye on. Stay tuned for more in "the 300 series."

'); for(i = 0; i < google_ads.length; ++i) { document.write('
• '); document.write('' + google_ads[i].line1 + '
  '); document.write('' + google_ads[i].visible_url + '
  '); document.write(google_ads[i].line2 + ' ' + google_ads[i].line3); document.write('
'); } document.write('