The JAR archives are well known to Java developers as they represent the distribution format bookstores and Java applications. But this format, which dates from the mid-90 is very well suited to its role as it is not easy to distribute or manage, so we spoke of "jar hell" ( "Hell the jar ").
Currently there is not, strictly speaking, management bookstores. Each application must provide the location of bookstores when it uses its execution, usually by changing its CLASSPATH, meaning that all the management of dependencies and versions is to manage when launching the application, which is specific to the operating system. In short it is tedious and require specific treatments for each operating system.
There is an alternative to "install" bookstores as an extension of the virtual machine, putting them in the lib / ext JRE, but given that there is no management of versions that may pose many problems, including other applications that explicitly specify their own bookstores, as different versions of the same library may find this at the same time. But in these cases it is not possible to determine the version to be used, and could even be used in part two different versions of the same book (which generally lead to a beautiful little obvious exception).
You can also find the opposite problem: an application with several levels of dependency can be lead to having to use two incompatible versions of the same bookstore, for example if it uses libraries A and B both of which require different versions of the C library . This is totally impossible now (but the problem is limited by the fact that bookstores Java external generally keep it as a backward compatibility).
Java 7 will try to solve all these problems via Java System Module, which will simplify the creation of modules (applications and libraries) by integrating support for the deployment in the Java platform and correcting major gaps on the jars.
[:]
Java System Module architecture containing four main components to manipulate bookstores / applications as "building blocks":
A common format for distribution (JAM), which aims to fill gaps in the JAR format.
A version manager to specify dependencies to other modules.
The repositories for storing, searching and retrieving modules.
The support of this mechanism within the loading of the classes of the virtual machine.
JAM: 2.0 JAR
JAM is an evolution of JAR format, with whom he also remains compatible (JAM an archive could be used as an archive JAR with JRE oldest). Indeed an archive JAM is nothing more than a JAR archive completed meta-data representing a "module". In practical terms it is simply a directory containing a JAR MODULE-INF METADATA.module with a file containing information specific to this module.
Such information includes, in particular, a number of mandatory elements:
Name: who will therefore identify the module with a unique name (containing the naming convention packages, ie using a domain name reversed).
Imports: who will list external modules used by this module, possibly with a constraint on the version number.
Class exports: who will find classes exported by this module (ie classes visible to other modules).
Members who will list all classes that are part of this module, including if they are not exported).
The meta-data modules may also contain additional information, among which are:
Version: which involve a number of specific version in this module, as defined in the following section.
Main Class: who will specify the name of the main class in the case of an application (like the attribute of the manifest of the same name).
Resource Exports: who defined the list of resources contained in the archive and visible from the outside.
Attributes: who will join the module to a set of attributes as "key = value".
Note that it is likely the type of meta-data can be extended thereafter.
You've probably noticed some similarities with superpackages, particularly in regard to meta-data required. This is not at all a coincidence, since a module will be made based on a superpackage and that the file METADATA.module will be generated automatically at the stage of compilation.
Thus the statement of superpackage helps to fill in all fields compulsory module: the name of the module will correspond to that of superpackage, and its contents will inform the list of modules imported, exported classes and class members. In addition, a number of annotations will insert the information optional. For example, you can use the annotation @ version specify the version of the module, and an annotation @ VersionConstraint to use when importing another module / superpackage to define constraints version.
For example, to define a module version "1.0" which uses two other modules with constraints on the version, you can use the following code:
/ / Declaration of superpackage:
@ Version ( "1.0") / / The module
superpackage com.site.pack (/ / Module name
/ / Import module com.site.name version 1.0 minimum:
@ VersionConstraint ( "1.0 +")
com.site.name import;
/ / Import module com.site.xml the family 1.5:
@ VersionConstraint ( "1.5 *")
com.site.xml import;
/ / List of packages that belong to this superpackge:
com.site.pack member package, com.site.pack.impl;
/ / List of exported types (visible outside the package):
export com.site.pack .*;
)
There will, of course, several other annotations to inform additional information modules, as @ ExportResources, @ ModuleAttributes, @ MainClass and others.
In addition to all these meta-data format JAM brings other advantages over the JARs:
It may contain native libraries in the directories / MODULE-INF/bin / <platform> / <arch> /, where <platform> and <arch> represent the system (example: windows or Linux) and architecture (example: x86 or x86-64). The virtual machine will do everything it neccessaire so these libraries are properly loaded via System.loadLibrary ().
It may itself be specific to a platform and architecture. A module of the same name can be declined according to the target platform, and be usable only on the latter.
It is possible to include JARs standard, whose contents can be exported or used as if they were classes or resources has directly in the archive JAM.
The archives JAM can be compressed with the compression format Pack200-gzip more efficient.
Versioning
The management of versions is a basic component of the Java System Module. Thus each module will be given a version number of the following:
major [. minor [. micro [. ]]][- update qualifier]
Fields major, minor, micro and update correspond to an integer value and represent a level of importance on the version. The field representative to major changes important (and potentially incompatible), while the scope update represents minor changes (for example, a correction that does not bug compatibility). Intermediate values allow you to specify changes versions intermediaries.
Finally, the field is to qualify any wording that could be used in development to differentiate the various compilations and developments of the same version.
Thus, it will be possible to specify version number as follows: "1", "1.7", "1.7.0.1", "1.7.0.2", "1.7.1", "1.7.2-rc" .. .
When using another module, it is now possible to define constraints on versions that can be used. These constraints can take the form of the three following syntax:
The syntax is open only define a minimum version number followed by the character '+', and any higher may be used. For example, with "1.5 +" will use all versions higher or equal to "1.5" (for example: "1.5.2", "1.6", "2.0", etc.)..
The syntax family limited compatibility to a family version, using the character '*'. A family is all versions starting with the same number. For example, "1.5 *" represent only the version number beginning with "1.5" (eg "1.5.2", "1.5.2.1", "1.5.4", etc.). But prohibit all versions higher as "1.6" or "2.0" ...
Finally syntax open with family: will set a minimum version number within a family. Using hooks to define the family of the minimum version. So "1. [+ 5]" represent all versions higher or equal to "1.5" within the family "1 *" (eg "1.5.2", "1.6", "1.7", etc.). But prohibit all versions above the "1 *" ( "2.0" then).
The following table gives a summary of all this:
Syntax
Description
Formula
1 +
Version 1 or higher (without coercion)
1 <= x
1.5 +
Version 1.5 or higher (without coercion)
1.5 <= x
1.5.2 +
Version 1.5.2 or higher (without coercion)
1.5.2 <= x
1 *
All versions of the family 1
1 <= x <2
1.5 *
All versions of the family 1.5
1.5 <= x <1.6
1.5.2 *
All versions of the family 1.5.2
1.5.2 <= x <1.5.3
1. [+ 5]
Version 1.5 or higher in the family 1.0
1.5 <= x <2.0
1.5. [2 +]
Version 1.5.2 or higher in the family 1.5
1.5.2 <= x <1.6
1. [5.2 +]
Version 1.5.2 or higher in the family 1.0
1.5.2 <= x <2.0
It will thus be possible to associate managing external libraries finely versions available, but more importantly it will be possible to use several different versions of the same module.
Note that it is also possible to use a Java class to deal with rules dynamically imports during the execution, and thus allow full control of bookstores.
Referential
The term of reference ( "repository") consists in fact the entire mechanism of storage, retrieval and loading of different modules and their definitions. It will revert to him that the burden of searching and loading modules according to their versions.
Each application will have at least one reference that will outline the API standard Java, and will be initialized by the JVM. But in addition to that each application may have other benchmarks, such as a global repository shared by all JVM, which would contain various plug-ins. The latter will simply be used by all applications.
Another example: An application can define its own repository containing modules which are specific.
Finally, a repository may, in addition to research and loading module, install or remove modules.
They should be two main types of reference:
The "Local Repository" who will handle the modules in a directory present locally on the system.
The "URL Repository" which will handle remote modules (eg HTTP) and download them in a local cache as needed.
It will thus be possible to add benchmarks command line when launching the application, or dynamically during its performance through the integration of a specific API.
These benchmarks will have to replace the notion of CLASSPATH currently used for the loading of classes, while allowing much more control (management of versions and dependencies, installation on the fly, insulation, etc.)..
Notices
The archives JAM provide many answers to the problems posed by JAR archives, and introduced mechanisms should allow deployment and a more flexible use of these libraries / modules, particularly with reference to the mechanism and versioning.
Like the superpackages, Java System Module is entered under the JCP through JSR 277 and would normally be present in Java 7. Can be found elsewhere in this document JSR Early Draft Review of more than 150 pages describing all the mechanisms to be put in place (and which are difficult to detail in a few lines).
We just have to see the impact that these changes may have on the Java platform, and if the move is so simple that promise ...
