The case for Java modularity

Two newer JSRs tackle an age-old problem

1 2 3 4 Page 4
Page 4 of 4


Access privileges and code authenticity are issues that Java has diligently tried to address from its inception, and these problems only get trickier in modular systems.

JSR 291

The security layer of JSR 291 is optional and based on the Java 2 security architecture. Code and JAR files can be authenticated by location and by signer. Admin permissions can be delegated to the framework deployer in order to restrict permissions to only those necessary for an individual bundle. Bundles can specify permissions for actions that extension or fragment bundles can perform, such as the permission to expose packages to another bundle, the permission to require packages from another bundle, or the permission to attach to another bundle. Bundles can only export and import packages for which they have the necessary permissions.

A resource in a bundle can be accessed via admin methods on the bundle. The caller of these methods must have admin permission privileges. Other actions that require admin permissions include calling methods to start or stop the bundle, loading classes that use the bundle, and retrieving the bundle context.

JSR 277

JSR 277 modules operate within the standard Java security model. Signing and signature verification for JAM files work just as they do for the JAR file format.

A new class, ModuleSystemPermission, is provided to be used by security policy providers in order to check invocation on some module system APIs. Some of these checks include installing new module definitions, uninstalling module definitions, creating a new repository, and shutting down a repository.

Migration from JAR files

The JAR file format has been the packaging and deployment standard for Java from the early days of the platform. Therefore, it is important for new packaging and deployment technologies to address the issue of migrating from JAR formats to whatever new format is introduced. JSR 291 and JSR 277 recognize this constraint and address it in different ways.

JSR 291

A JSR 291 bundle is based on the JAR file format with additional information, such as an enhanced manifest file and optional documentation. In a JSR 291 framework, a bundle is deployed as a standard JAR file with specific additions made to the JAR file manifest, including the bundle name, the bundle version, exported packages, and so on. A bundle JAR file can contain other JAR files.

JSR 277

The JAM format of JSR 277 is based on the JAR file format, with the addition of a METADATA.module file placed under the MODULE-INF path in the JAR file.

JAM files can be compressed using a hyper-compression scheme known as Pack200. This compression technology was defined by JSR 200; it reduces the size of JAR files by optimizing storage of specific features of Java classfiles. For instance, it removes redundant class attributes and merges constant pool data.


Because Java aspires to a worldwide reach, it has always offered facilities for localization, offering an instance of a component or module for consumption with the necessary manipulation of text and other resources to fit a given locale and language.

JSR 291

In JSR 291, the Bundle-Localization manifest header contains information about the location in the bundle where localization files can be found. The default value is OSGI-INF/l10n/bundle. Localization files use a naming scheme somewhat similar to the standard resource bundle localization scheme used for Java SE. Specifically, localization files share a common base name followed by an underscore and one or more suffixes (denoting language, country, and variant) as defined in java.util.Locale. The localization file must end with the .properties suffix. For instance, an English localization file would be OSGI-INF/l10n/, while the Swedish version of this file would be named OSGI-INF/l10n/

JSR 277

No explicit mechanisms for localization are defined in JSR 277 outside of what is already established by the Java SE standard.

Java modularity: Where do we go from here?

The need for a Java modularity standard is apparent. However, the future is still very much in question. JSR 277 is still in draft review, and very little activity is emerging publicly from the expert group. Based on recent discussion, it seems the JSR 277 expert group is determined to make JSR 277 interoperable with JSR 291. In contrast, JSR 291 is in the final release stage, and has gone through several significant revisions; moreover, it is based on OSGi, a platform already in wide use.

In conclusion

The need for a modular component system for the Java platform has been apparent for almost as long as Java has been known to the mainstream software development community. JSR 277 and JSR 291 seek to fulfill many of the same requirements of a modular system of components.

JSR 277 approaches the problem from the perspective of the JRE by defining Java API enhancements, a distribution format, a versioning scheme, a module repository, and a set of support tools.

JSR 291 exploits the popularity of the OSGi system of modularity with a module system that includes a module assembly framework, a service layer, a strict component lifecycle, and a mechanism for exposing services from modules.

The different approaches taken by each JSR expose and address some of the deficiencies found in each, but there's also a high degree of overlap that could prove confusing. Many have proposed that the ideal solution lies in the two working well with each other. Modules written to one specification ought to work in the other, and each project should support Java-language enhancements proposed by the other.

See the Resources section to learn more about the topics discussed in this article.

Jeff Hanson has more than 20 years of experience in the software industry, including work as senior engineer for the Microsoft Windows port of the OpenDoc project and lead architect for the Route 66 framework at Novell. Jeff is currently the chief architect for Max International and builds service-oriented frameworks and platforms for Java EE-based enterprise systems. Jeff is the author of numerous articles and books, including .NET versus J2EE Web Services: A Comparison of Approaches, Pro JMX: Java Management Extensions, and Web Services Business Strategies and Architectures.

Learn more about this topic

This story, "The case for Java modularity" was originally published by JavaWorld.

Copyright © 2008 IDG Communications, Inc.

1 2 3 4 Page 4
Page 4 of 4