JSR 277 is to define
"a distribution format and a repository for collections of Java code and related resources. It also defines the discovery, loading, and integrity mechanisms at runtime."
… which sounds a lot like components to me. In particular, they’re hitting a lot of my "hot buttons" regarding the use of Jar files when they write in Section 2:
Java Archives (JARs) are widely used as both the distribution and execution format for Java applications. The JAR format dates back to the mid-1990s, and it has not scaled particularly well in either of these roles. JAR files are hard to distribute, hard to version, and hard to reference in general.
Amen to that, though I would take issue with the idea that they’re hard to distribute–a bit more verbose and/or less compact than we’d like, perhaps, but not a killing blow. The lack of versioning and references between Jars, though, that hurts.
Distributing a simple Java application is considered to be a complicated task by many developers because it often involves creating a native installer to package multiple JARs into a distribution unit, and it sometimes involves converting the application into a Java applet or JNLP (Java Network Launching Protocol) application for web-based deployment.
Oh, sing it loud, sing it proud. Doing standalone/"rich client" Java application installations has been "Unzip this .jar file" for far too many years. (In truth, it’s a testament to Java’s standalone versatility that we could get away with that for this long, but we certainly could use something a bit more robust and standardized.)
There is no built-in versioning support in the JAR format. There is no reliable mechanism for expressing, resolving, and enforcing the dependency of one JAR upon another. Referencing a JAR, moreover, involves specifying it in the classpath. Since the path of a JAR may change during deployment, developers are forced to fix up all the references to the deployed JARs as part of the deployment process.
Yes! But let’s be careful here, too, as one of the leading candidates for Java to model itself after (.NET) has it’s own share of issues in this space, too, and simple referencing of modules (as I guess they’ve decided to call them) isn’t necessarily going to solve all of our problems, either. It’s a good start, though….
Developers also find it quite difficult to deploy installed Java extensions (a.k.a optional packages) because they can easily run into issues like versioning conflict and namespace collision. Java extensions can currently only be installed into a specific Java Runtime Environment (JRE); it is basically impossible to arrange for an installed extension to be shared across multiple JRE installations.
This is one of the first areas I disagree with the proposal thus far; the ability to set extensions on a per-JRE basis is one of Java’s strengths, in my opinion, and helps avoid some of the versioning/side-by-side issues that are currently plaguing the .NET crowd, specifically those who are at work trying to integrate SQLServer and .NET 2.0 together. (Microsoft’s recent pullback from "lots of managed code in the OS" stance for Longhorn is a testament to the concern over the problem, since–as it’s been explained to me–the concern is essentially one of how to version the .NET runtime without breaking Longhorn code in the process.) One of Java’s strengths is its multiple JRE stance–let’s not do anything to essentially break that.
The specification of the Java Module System should define an infrastructure that addresses the above issues. Its components are likely to include:
A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources. The metadata would contain information about a module, the resources within the module, and its dependencies upon other modules. The metadata would also include an export list to restrict resources from being exposed outside the module unintentionally. The metadata may allow subset of exposed resources to be used by other modules selectively.
A versioning scheme that defines how a module declares its own version as well its versioned dependencies upon other modules.
A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support.
Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules.
A set of support tools, including packaging tools as well as repository tools to support module installation and removal.
This is awesome. This is exactly what Java’s needed for years. I wish it had been there from the beginning, but I guess 10 years later isn’t too bad, as major improvements in the environment go. And make no mistake about it, this is about as major an improvement to the platform as you can get without significantly rewriting the ClassLoading scheme from the ground up.
Now if we can just get the Isolates JSR back off the ground….