JSR 277, Java Module System has been submitted this month by Sun. The target is to solve Jar deployment problems. I think that this initiative was needed since a long time. Relationships and dependencies between Jars cannot be enforced and consequently managed properly at deployment time. But it seems that this JSR is only a part of the solution to this problem. Let?s take an example. I have a component x.jar that requires log4j-1.2.8 and another component y.jar that requires another version of log4j. What happens if my application uses both x.jar and y.jar ? Today, it is already possible to define jar dependencies in the jar file manifest. But as soon as we have 2 different log4j implementations with identical names and packages for some interfaces or classes, the class loader will load only one of the 2 implementations according to which jar comes first in the class loading process.

In J2EE, it?s the same behavior, we might have less problems between war files because those web apps get their own private classloader but we still have the problem for EJBs that all share the same classloader.

One of the possibilities is to use different class or package names in each version of the jar files we use (log4j jar files in our example). By doing so, we can perfectly have at the same time different implementations loaded. But who?s doing that? Nobody! Developers hate version numbers in package names and class names for the simple reason that they want to minimize the effort of upgrading to a new version.

The result is that we are now obliged to choose for one single version of log4j and try to have both components happy with it. Could become a painful experience when the number of jars in an application grows.
So having dependencies managed between Jar files is a good thing but the goal should be to let the classloading mechanism follow the move.

I would like to have x.jar and y.jar using each their own version of log4j in their own private virtual machine memory space. This behavior should not be the default behavior but could be configurable before or after the jar creation time.

Relaxing the classloading principles, taking into consideration the where the invocation of a jar file is coming from looks to me as the most challenging part. This change should target J2SE and J2EE from day 1.

Is that the scope of this JSR 277?

I will meet Stanley Ho, who is the spec leader of this JSR today. I will keep you updated.

Straight from the BEA JavaOne keynote

BEA will certify and support the open-source frameworks such as Struts and the Spring Framework.

BEA has signed a partnership with Interface21, the company behind the Spring Framework.
This means that developers will receive support via helpdesks and probably SLA's will also
cover these open-source frameworks. The integration with these open-source frameworks will
be available in the next release of the BEA WebLogic Server.

BEA will also support other production deployment environments such as Tomcat and Geronimo
from within the Eclipse BEA plug-in environment. (I'm again happy to be a BEA Technical Director)

Wauw I never would have thought the above open source "products" would be linked to each
other in the same blog post. So is there an Oracle and IBM keynote at JavaOne where Rod will also speak ??!

The only main API which is missing in the BEA portofolio is support for Enterprise Java Beans version 3.
I was hoping to get an announcement that BEA would have acquired an EJB 3.0 company like Solarmetric...
maybe at JavaPolis this year

This means that BEA developers will now have access to new techniques like Aspect Oriented Programming,
Inversion Of Control and wiring of Beans resulting in a very loosely coupled environment.

Good stuff !!!

-Stephan
PS: Thanks to Gerard Maas for the great foto's.

Free JavaOne Content ??!

I was really waiting for SOA related content from this 10th edition of JavaOne.
Vendors do have all SOA on their lips for the moment, and I believe there was a lot to be said about Service Oriented Architectures.

The few presentations I have already seen were disappointing at best. I am now getting a very introductory session about SOA, showing that there is still a long way to go in the perception of what a SOA really is.