Skip to main content

Change the World

Posted by editor on October 30, 2006 at 7:16 AM PST

Deeper into the JSR-277 debate

Consciously or not, I've been going back and forth with positive and negative front page items relating to JSR-277, the Java Module System, which aims to offer a radically overhauled vision of distribution and versioning of Java applications, in the Java SE 7 timeframe. During this public comment period, you can download and read the public spec, but it's a sufficiently big document that it can be easy to miss the forest for the trees. Moreover, just reading the spec misses the context that JSR-277 is being developed in -- some of the criticism is not so much about what JSR-277 proposes to do, but how and why it differs from extant systems with similar goals, and in how the expert group conducted its business while developing the spec.

Stanley Ho's blog JSR-277 Early Draft Specification offers a good overview about some of the key features of the proposed spec, and more importantly, why they're there. One key point is why JSR-277 doesn't currently address more sophisticated problems that other systems tackle. Stanley says that JSR-277 is simpler by design:

We deliberately made the design simpler by following this principle - make simple things simple, and make complex things possible. Because JSR-277 is targeted for Java SE 7, we have flexibility to update the JVM and classes libraries in the SE platform to better support JSR-277, thus reducing the overall design complexities. Also, the JSR-277 architecture is very extensible - 3rd parties may plug custom implementations to address complex or unforeseeable cases when these cases arise, so the core architecture can be kept simple.

Note: It is also fair to say that the module system described in the early draft is relatively simple because the early draft is by no means complete.

He also points up a design goal of extensibility, which has not been a major point of 277 discussions thusfar:

A trademark of many Java platform APIs is extensibility and allows 3rd parties to deliver innovations that plug into the JRE. For example, ClassLoaders, service providers, etc. JSR-277 is not only a module system by itself, but it is also an architecture that is extensible by other module systems (e.g. OSGi, NetBeans, etc.). Although the details still need to be worked out, the goal is to allow some degrees of interoperability between JSR-277 and other module systems. By providing custom module and repository implementations, other module systems may expose their modules through the repository for other JSR-277 modules to import. Similarly, through the powerful JSR-277 reflective APIs, other module systems may also allow their modules to import JSR-277 modules.

Some of the feedback is already asking questions about the early criticisms of 277, and Stanley says he'll talk to some of those points in a future blog.

At any rate, the early draft review closes in two weeks, and it promises to continue to be an interesting discussion. Do join in...

Also in today's Weblogs
Sahoo has a tutorial on
Persistence Context propagation:
"While using Java Persistence API in an enterprise application, there is often a need to access access entities in the same persistence context in different components involved in a particular request. Using a very simple Java EE application, this article shows how to achieve this in an elegant and portable way. The technique described here is completely portable across any Java EE 5 compatible application server because it uses a standard feature called persistence context propagation."

Finally, Hans Muller realizes a few holes in the Swing spec make it hard to show a dialog appropriately, which led him to post a
Dialog Diatribe:
"A menu item whose action creates and shows a new dialog which is centered over (and owned by) the menu item's frame, should be a no-brainer. I found the some quirks in the process, they made me cranky, and so I wrote about it."

In Java Today,
the Spring Web Flow team has released version 1.0 after 20 months of active development. The release comes after 11 milestone releases and 50k early access downloads. Spring Web Flow allows developers to build reusable, self-contained controller modules called flows. These flows can then be used with the developer's web framework of choice. In Keith Donald on Reuseable UI Flows with Spring Web Flow 1.0, Scott Delap interviews Keith Donald, Spring Web Flow Lead about the project and how it compares to other Java web application frameworks.

Those who've been waiting fort the next version of NetBeans and its various companion projects can jump over to the products page: " is pleased to announce the release of NetBeans IDE 5.5 FCS
together with Mobility Pack FCS, Profiler Pack FCS, Enterprise Pack FCS,
C/C++ Pack (Beta 3) and Visual Web Pack (Technology Preview). This
NetBeans release supports the Java Enterprise Edition 5 platform, and
most notably the Java Persistence, EJB 3 and JAX-WS 2.0 specifications."

The Java Desktop Community home page recently highlighted Prefuse, a Java-based toolkit for building interactive information visualization applications, supporting a rich set of features for data modeling, visualization, and interaction. It provides optimized data structures for tables, graphs, and trees, a host of layout and visual encoding techniques, and support for animation, dynamic queries, integrated search, and database connectivity. Written in Java, using the Java 2D graphics library, Prefuse is easily integrated into Java Swing applications or web applets.

In today's Forums,
neilfraser could use some advice about
Changing the URL of the target web service:
"I have a WSIT client to a WCF hosted Web Service and have the two ends communicating. When it comes to deployments, the address of the target Web Service will be different per installation and so this needs to be made configurable. Again I found this to be quite straightforward. However, for my generated web service client, the constructor I need to use to dynamically specify the location of the target Web Service takes the address of the WSDL as a parameter. Once we deploy our Web Services we don't want a client or browser to be able to query the WSDL. Is it possible to create a Web Service client instance without needing to specify the address of the WSDL? Does the underlying Service class use the WSDL to update it's definition each time? If it does, is this so that it can pick up configuration changes to the service on the fly?"

kleopatra passes along a little nugget of Swing wisdom in
Re: Resizing strangeness in MultiSplitPane:
"I can't say anything about the MultiSplitPanes as such - but as a general rule it's a no-no-never to call setPreferredSize in client code anywhere. If that appears to be necessary, than something is wrong somewhere ..."

Heavyweight/lightweight issues? trader_stuart
Cannot use dropdown or menu above WebBrowser:
"I have tried to use a combobox above the WebBrowser instead of the textfield that is used in the demo code. Only problem is that when you select the dropdown it disappears behind the WebBrowser object. Same thing happens if a menu is placed above the WebBrowser Is there some way to avoid this happening or is this a bug?"

In today's
News Headlines

Registered users can submit news items for the href=""> News Page using our
news submission
. All submissions go through an editorial review before being
posted to the site. You can also subscribe to the href=""> News RSS

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.

Deeper into the JSR-277 debate