Advertisements
Introduction
This article explains the new Java Module System that will be included in the Java 7.0 release. Modules are new to the java language and they provide a standard for developing and deploying applications. The article will explain the various sub components that are available as part of the Java Module System's architecture. The various sections discussed in the article will provide in-depth details about the module definition, the metadata associated with the module, the versioning system and the repositories for storing and retrieving the module definitions.
Java Module System
The architecture of Java Module System consists of three main components:
* Java Module
* Versioning System
* Repository
A Java Module is a distribution standard that contains set of classes and resources similar to a Java Archive File. What differs from JAR from a JMS (Java Module System, not Java Messaging System) is that the modules can be versioned. The Java Module System contains a metadata file that contains information about the inclusion of classes, resources and the set of jar files that this module is dependant on. Versioning of a java module is explained in detail in the following section. The specification of Java Module System also defines a repository whose Java Module files can be stored, discovered and used by other modules.
Module
Before going into more details, let us look into the various terminologies and the individual components that are related to a Java Module System.
A module or a module definition can be defined as a logical unit of set of files, resources and its dependencies that can be versioned, packaged and deployed in the module repository for re-use by some other application. Each module consists of a module meta-data that is self-describing. Given below is the major breakup of a module metadata,
* Name of the module
* Extensible meta-data that includes version, resources, exports from this module, etc..
* List of imported modules
* List of classes contained in this module
For example, consider the following metadata for a module definition by name net.javabeat.config with the version 1.0,
module
(
name = net.javabeat.config
extensible-metadata = [@Version("1.0")]
)
Module Exports
Classes and resources that are available in one module can be exported so that other modules can re-use by importing them. For example, consider that a module called net.javabeat.util is developed containing three classes: ClassA, ClassB and ClassC. Assume that ClassC is a public utility class that is to be re-used by some other modules. In this case, the requirement can be made to achieve by having the following module definition,
module
(
name = net.javabeat.util
extensible-metadata = [@Version("1.0")]
class-exports =
[net.javabeat.util.ClassC]
members =
[net.javabeat.util.ClassA,
net.javabeat.util.ClassB,
net.javabeat.util.ClassC]
)
Module Imports
A module can import other module for accessing the classes and the resources. Note that, only the set of classes and the resources that are exported can be referenced and used by the imported module. The following module net.javabeat.app imports the example module net.javabeat.util that was created in the preceding example,
module
(
name = net.javabeat.app
extensible-metadata = [@Version("1.0")]
imports =
[ImportModule(net.javabeat.util, @VersionConstraint("1.0"))]
members =
[net.javabeat.app.ClassA,
net.javabeat.app.ClassB,
net.javabeat.app.ClassC]
)
