JSR 296 in coma ?

I’ve been checking the upcoming features of Java 7 and found a cool detailed list here. Also, some Java One 2008 slides from Danny Coward’s presentation show a little on that too.

Among the JSRs mentioned in the first link, I already had checked some stuff from JSRs 277, 294, concerning Java Modules, JSR 284, concerning resource consumption and JSRs 295, 296 and 303 concerning Swing.

I’ve known these swing-related JSRs since, more or less, they became available as JSRs. I had special interest on them at the time because I was working in a project where we needed a product built on top of a Rich Client Platform, to enable the development of plugins from third parties. The idea was to have a simple and pluggable structure.

For us, Eclipse RCP was overkill so was the Netbeans platform. Spring RCP was in its initial stages. We’ve decided to go from scratch, using OSGi as the base for a pluggable architecture, and build our own straightforward RCP. The JSR 296 (Swing Application Framework) proposes most of what we needed (and developed) as a Swing foundation for our RCP:

• Resource management for i18n
• Task services/monitoring
• Storage for session state
• Events/actions framework
• Managed application exiting (exit listeners), startup, shutdown
  

I can't say that this is a PCP (Poor Client Platorm). Maybe an ARCP (Almost Rich Client Platform). But, as I said, it does most of what we needed at that time. And I believe there are hundreds or thousands of other applications that don't need all the heavy richness provided by the RCPs.

So I decided to take a look at JSR 296 (Swing Application Framework) to see what they have for us so far. I’ve downloaded it from the project site. (You should also need to download the SwingWorker since they do not use the SwingWorker delivered with Java 6)

This tutorial has good examples concerning the features of the JSR 296, like the magic stuff for saving session state (components dimensioning, positioning, etc):

//The non-qualified getters below are inherited from the SingleFrameApplication class
//
//Saving session State
getContext().getSessionStorage().save(getMainFrame(), sessionFile);
...
//Restoring session State
getContext().getSessionStorage().restore(getMainFrame(), sessionFile);

Lots of weeks of modelling and coding can be saved by using that framework.

There was a weird thing about the last available version: it was from November 2007. It seems that it is not evolving anymore. I’ve read a few months ago in blogs that I don’t recall, that some senior engineers from the Swing team were leaving Sun Microsystems. I could find this blog entry mentioning some of them.

The guys that took care of JSR 296 (Hans Muller) and 295 (Scott Violet) are gone. However, I think that there are no worries with JSR 295 and 303 which are just “standardizing” the concepts used in JGoodies by Karsten Lentz, who is a member of both expert groups. But the JSR 296 is apparently a home grown implementation from Sun. The guy that was handling that is gone, and there are no new versions for 8 months.

Weird… It appears that the project is in some sort of "coma".

Don’t know if it will make it until Java 7

Heap snapshot analysis and objects with different class versions

I’ve been working lately on the detection of a particular problem, called stale references, that may happen on OSGi based applications. It is a consequence of bad OSGi programming practices that may lead to memory retention and the utilization of inconsistent objects.

As a part of the diagnosis process I need to analyze heap snapshots to find the referrers of services that have been unregistered. I’ve found some interesting stuff (at least for me) concerning memory inspection and classloading. Each module (bundle) in OSGi is provided with its own class loader instance. If you replace (update) a module during runtime, it will basically stop, refresh and restart; and get a new class loader. Objects and classes from the previous class loader must not be referenced anymore, and that previous CL is supposed to be “discarded” and GC’d.

In our custom tool I was seeing that objects from “discarded” class loaders were still being referenced by other modules. However, when I used JHat (either embedded or standalone) to inspect the heap snapshots by performing queries like “select x from com.foo.TheClassOfTheReferencedObject” the result set listed only one object instance (from the running module) when I was supposed to get two instances (one loaded by the old class loader and other by the new one).

I thought my tracking code was falsely accusing the service object from the old bundle version. After patiently and manually (maybe “stupidly”) verifying each class loader instance, I found the two different class loaders that referred to the same bundle ID, and could also found the “lost” object.

After a few weeks I’ve tried to track the same problem with the heap inspection provided in the VisualVM. It worked like a charm! I could see all object instances of the same class name, no matter what class loader provided the object class. It does not have advanced queries like JHat, but in this case I only needed a filter to find the class instances that interest me.

It’s a pity. JHat has powerful queries to analyze heap snapshots, but it can’t deal clearly with the same class names loaded by different class loaders (i.e. different versions of the same class). VisualVM has much more limited power that JHat, but allows to see attribute values, referrers and referring trees just like JHat. In addition, VisualVM deals with no problem with classes carrying the same name but loaded by different class loaders, and that what’s more interesting for me, at least for now.