Felipe Gaucho's Blog: Community: Java Specification Requests Archives

Classpath Hell: Where are your classes and libraries? Why different IDEs use different folders? Does it matter?
JAR Hell: How to deliver different libraries in only one JAR?
Extension Hell: Remember that nightmare when a different version of a class was being loaded from an unexpected JAR?

Well known problems like How to deliver applications in only one JAR and the version control and management of dependencies between different modules of an application motivated these researchers to propose something better for the next generation: a Super JAR mechanism that allows developers to simplify development and deployment processes. As you will read in this entry, Maven seems to be quite similar to this new specification, but there are some enhancements in parts were Maven and other integrator mechanisms failed in the past. It is a new idea based on old problems, so the solution is a collection of best practices and learned lessons, including an elegant conflict resolution that sometimes reminds us of operational systems algorithms. During JavaOne, most part of the session was consumed by explanations about the conflict scenarios and the strategies the authors were proposing to avoid them - tricky but also very interesting.

What is a Module?

A module is a set of artifacts that can be executed as an application or artifacts that can be part of an application - including libraries, classes, files and any other resource required during the runtime. From the specification:

	A Java module is a unit of encapsulation. It is generally written
        as a development module	in a programming language in the Java platform,
        and is ultimately compiled into meta data and packaged together
        with classes and other resources as a deployment module.

The goal of the new specification is a first class modularity:

Versioning scheme: the nowadays JAR format does not support versioning, what means the correct version of the libraries should be controlled by developers and deployment engineers. Usually we adopt name conventions to solve conflicts and to alert the users about the library version, but we all know this is error prone. The authors suggested to include some versioning scheme with runtime validation process, solving the first hell.
New distribution format (JAM): JAM comes from Java Module, and it is based on the JAR file format plus some advantages:
- Signed JAM files: the signing and signature verification for a JAM file are identical to those for the JAR file format in the Java SE platform. A JAM file can be signed and verified using, e.g., the standard jarsigner tool from the Java SE SDK.
- Compressed JAM files (Pack200): Pack200 is a hyper-compression scheme for the JAR file format, and it is defined in JSR-200. The JAM file format is based on the JAR file format, hence developers may use Pack200 to further compress a module archive (i.e. a JAM file) for distribution.
- Fine grained security in JSE 7: they are looking to use some Java 7 proposed features to enhance the security level of the JAM files, including the ability to reduce the visibility of some resources through manifest configuration. It is not included in the current specification, but is a good outlook.
Repositories: this part is Maven-like, but with some new features like repositories hierarchy. Several repositories (bootstrap, global, application, local, URL) can be accessed during the runtime to resources retrieval, and some naming and versioning conflicts can occur during this process. The resolution of these issues is an important part of the JSR-277, but I invite you to check the early draft about that because it is not something I can summarize in few lines of a blog :)
Runtime support: a great advantage of the Module System over Maven and other integrators is the Runtime support. Proposed to be part of the JRE, the new mechanism will receive a privileged treatment during the startup of applications, and all its features will be executed by the virtual machine itself instead of a third-party code. Runtime will include validation of modules, a wonderful feature that brings the Java developers full control about which resource and which module will really be used by their applications.

A lot of information for a simple blog, but the subject is fascinating and I guess the new Module System can give us a much better control over our deployment tasks in a near future. I strongly suggest you to visit the specification download page, read the early draft and start preparing to change your configuration procedures in the next year.

Powered by
Movable Type 3.01D

java.net RSS Feeds