Help

It was almost a year ago that Mark Reinhold (one of the top Java engineers over at Sun/Oracle) announced The classpath is dead! at JavaONE, accompanied by a series of blog posts like this one, proclaiming that the future of Java is a modular one. In the mean time, the JDK 7 timeline has slipped dramatically and we may not see modules in Java proper until 2012 or later. All the while, the folks on JSR 294 have stalled, started, and stalled again, slowly inching their way towards a tightly-Java-integrated modularization standard, possibly requiring significant language, bytecode, and packaging changes to support it.

I've long maintained that it would take far less than this to introduce a solid, usable modularity standard. And as part of our JBoss AS 7 proof-of-concept work, we've proven it with the creation of JBoss Modules.

What is in a module?

If you haven't been following the developments around JDK 7, you may not even be aware of what you're missing.

A module is any collection of classes and resources, associated with a single class loader. Modules may express a dependency on other modules. The exported classes and resources from these dependencies are visible to classes in the dependent module. Visibility is the ability of a class from one class loader to see a class from another class loader. To export a class or resource means to make such a class or resource visible to dependents.

So what a module system provides is a way to package up classes and resources into modules, and establish a graph, at run time, of class loaders such that all the expressed dependencies are satisfied.

What's so great about modules?

The traditional method of running an application in Java uses the well-known classpath mechanism. This basically creates a single application class loader with all those JARs' resources concatenated together in one big blob.

Now imagine you have a very, very large and complex application with dozens of JARs. Imagine that some of those JARs are not used all the time, or that some of those JARs represent multiple, conflicting versions of the same classes and packages due to conflicting dependencies. This problem, and other issues along these lines, are known popularly as Jar Hell.

Modules can greatly alleviate this problem. When all JARs are bundled as modules, a JAR will never see a conflicting version of a dependency class, or pick up resources from other JARs inadvertently. Also, a module which is never used will never be loaded which can improve startup time of large applications.

Why wait?

JBoss Modules is a standalone module system for Java 6 and up. It supports the following features (and more):

  1. An memory-efficient, high-performance, concurrent/thread-safe delegating class loader implementation, capable of loading any class or resource in O(1) time
  2. An extensible module loader system which allows users to plug in alternative module definition/loading strategies
  3. An easy-to-use bundled local module loader, which loads modules (packaged as standard JARs or as exploded directories) from the filesystem in a simple, predictable structure (think Maven, but simpler)
  4. An easy bootstrap process (see below)
  5. A useful runtime API for loading modules, getting a class loader for modules, creating modules at run-time, extending the JDK service loader mechanism to be module-aware, and more
  6. Management of platform-specific native code

A modularized program is started like this:

java -jar jboss-modules.jar -mp path/to/modules my.main.module.name

In your module path (-mp) you specify the root directory (or directories) which will be searched by the default module loader for module definitions. A module is defined using a simple XML descriptor, like this:

<module xmlns="urn:jboss:module:1.0" name="org.jboss.msc">

    <main-class name="org.jboss.msc.Version"/>

    <resources>
        <resource-root path="jboss-msc-1.0.0.Beta3.jar"/>
    </resources>

    <dependencies>
        <module name="org.jboss.logging"/>

        <!-- Optional deps -->

        <module name="javax.inject.api" optional="true"/>
        <module name="org.jboss.threads" optional="true"/>
        <module name="org.jboss.vfs" optional="true"/>
    </dependencies>
</module>

There is a full schema bundled in jboss-modules.jar for this descriptor format, so integration with your favorite IDE is easy. There are also many extended capabilities available which allow tight control over what packages are exported or imported, and you can also selectively exclude content from your resource JARs (making it even easier to use prepackaged JARs).

How does this compare with JSR 294?

This simple module system has several advantages over JSR 294 as it stands today.

  1. It's available now. There is no telling when JDK modules will become available - maybe in Java 7 in 2012, maybe in Java 8 or later. This is a project you can use - and contribute to - today.
  2. No invasive language, bytecode, or compiler changes are needed, and no JCP approval is necessary.
  3. As things stand today, JBoss Modules should be compatible with JSR 294, and we will strive to maintain compatibility if and when Jigsaw solidifies and becomes part of OpenJDK.

How does this compare with OSGi?

  1. It is much simpler; one JAR is all that is needed to get your modular application off the ground.
  2. It is minimal: there is no services layer, or any other higher level functions that OSGi provides. It does exactly one thing, and it does it well.
  3. At the same time, it is very powerful, and could form the basis of a class loading framework which an OSGi implementation could use (more on this in the future, stay tuned!).

What is the current status?

JBoss Modules is available now via Maven as org.jboss.modules:jboss-modules. There is also a JIRA Instance available for reporting problems. Discussion relating to Modules in AS 7 happens here or on #jboss-msc on FreeNode IRC (join via webchat with your registered nickname). The source code is hosted on GitHub.

So... what are you waiting for?

22 comments:
 
10. Sep 2010, 20:01 CET | Link
Zemian Deng

Hello David,

Shouldn't it be jboss-modules.jar instead of jboss-modules.java in this line:

java -jar jboss-modules.java -mp path/to/modules my.main.module.name

Also what should the descriptor file be named? Will it go under META-INF or just in classpath?

Would the source be part of JBoss 7 trunk, or is there seperate source repository url?

ReplyQuote
 
10. Sep 2010, 20:17 CET | Link
Gary Struthers

JBoss Tools now builds with Sonatype Tycho which uses OSGI. It's baffling that JBoss now goes in a different direction.

 
10. Sep 2010, 21:00 CET | Link

Yeah that was a typo, thanks for the catch.

 
10. Sep 2010, 21:03 CET | Link
Also what should the descriptor file be named? Will it go under META-INF or just in classpath?

For the default local module format, the module.xml file goes on the filesystem next to your JAR(s) or file resource roots for that JAR. Of course the module loader system is extensible, so you can also support descriptors in META-INF or in the Manifest or elsewhere.

Would the source be part of JBoss 7 trunk, or is there seperate source repository url?

The source code is available on GitHub. Patches are welcome!

 
10. Sep 2010, 21:05 CET | Link
JBoss Tools now builds with Sonatype Tycho which uses OSGI. It's baffling that JBoss now goes in a different direction.

JBoss Modules is not a different direction: rather it's apples and oranges. JBoss Modules can (and probably will) be used as the basis of an OSGi runtime in the future. However by itself, it's much simpler and lower-level, so if you don't need all the OSGi functionality (in particular, the runtime), it may suit your project better.

 
27. Sep 2010, 13:22 CET | Link
PETER KRIENS | Peter.Kriens(AT)aQute.biz

Sigh ... Simple or Simplistic? That is the question ...

 
27. Sep 2010, 17:23 CET | Link

Just to address your points in the OSGi comparison section:

1) OSGi is also just one JAR. At least Equinox and Felix are... I'm not sure about Knopflerfish implementation.

2) OSGi is also minimal. 9 core classes and 15 interfaces (excluding Permissions). The service layer is, as the word layer suggests, cleanly separated from the module layer. Its entirely optional to use it.

3) It seems unlikely you would be able to implement OSGi on top of JBoss Modules, because (so far as I can tell) you support only whole module dependencies, i.e., what we would call Require-Bundle in OSGi terminology. It's more likely that you could implement JBoss Modules on top of OSGi.

 
27. Sep 2010, 22:24 CET | Link
3) It seems unlikely you would be able to implement OSGi on top of JBoss Modules, because (so far as I can tell) you support only whole module dependencies, i.e., what we would call Require-Bundle in OSGi terminology. It's more likely that you could implement JBoss Modules on top of OSGi.

"Doubting Neil", I guess you'll just have to look here: http://jbossosgi.blogspot.com/2010/09/jbossosgi-100beta9-released.html ;-)

 
27. Sep 2010, 22:43 CET | Link
Neil Bartlett wrote on Sep 27, 2010 11:23:
Just to address your points in the OSGi comparison section: 1) OSGi is also just one JAR. At least Equinox and Felix are... I'm not sure about Knopflerfish implementation. 2) OSGi is also minimal. 9 core classes and 15 interfaces (excluding Permissions). The service layer is, as the word layer suggests, cleanly separated from the module layer. Its entirely optional to use it. 3) It seems unlikely you would be able to implement OSGi on top of JBoss Modules, because (so far as I can tell) you support only whole module dependencies, i.e., what we would call Require-Bundle in OSGi terminology. It's more likely that you could implement JBoss Modules on top of OSGi.

The default interface is indeed geared towards whole-module dependencies, which I still believe to be a more reasonable method than package-oriented wiring (I've long thought that conflating packages and modules is a mistake). However the SPI enables very dynamic behavior (including functionality enabling fragments, dynamic imports, relinking, and all the other crazy stuff that OSGi allows), while still using the highly efficient O(1) class loading system. For an example, see JBoss OSGi's latest release.

The core system is actually highly flexible, but the basic interface is geared towards what I think is a much more common set of usage patterns than what is generally recommended by OSGi advocates. That is, of course, my opinion and I'm sure it differs from many.

 
27. Sep 2010, 22:46 CET | Link
PETER KRIENS wrote on Sep 27, 2010 07:22:
Sigh ... Simple or Simplistic? That is the question ...

Simple, of course :)

 
28. Sep 2010, 12:04 CET | Link
David Bosschaert | david(AT)redhat.com

My experience with jboss-modules is that it's really super fast and simple. It lacks many of the features that OSGi has but in some cases that might be ok. For all the other cases, we're building the JBoss OSGi framework on top of jboss-modules which provides all the nice value-add that OSGi offers: package-level imports and exports, versioning, OSGi Service registry and so on...

 
04. Oct 2010, 21:15 CET | Link
Sangjin Lee

Do you have an eclipse plug-in or any other tool that helps you the development of these modules? Or is it left to the students as an exercise? :) Thanks.

 
13. Oct 2010, 05:32 CET | Link

No, there is no IDE integration as of yet, since this project is fairly young. However the isolation concepts in Modules closely match how most IDEs express dependencies, so it should not be too difficult to make the leap if you're working with IDEs. Time will tell whether IDE integration is something that people can use with this project; modularized building is another topic in a similar vein which could use some exploration as well.

 
25. Nov 2010, 19:16 CET | Link
Stuart McCulloch | mcculls(AT)gmail.com

Does the module schema support replaceable dependencies? ie. Say I have a dependency to another module that implements a particular API, but I don't care what module is used as long as it implements this API. Or in other words, my application may require a DI framework that supports JSR330, but I don't want to choose between Spring or Guice when I write the module definition. How can I encode this dependency without naming a specific module?

 
26. Nov 2010, 10:02 CET | Link

Great! Very interesting, specially the extension of the JDK service loader mechanism. :) There is also Simple Dynamic Modules that is able to create a dynamic module from a regular maven artifact. There is also a simple service layer on top of the modules.

 
28. Nov 2010, 19:54 CET | Link

It's mainly a question of usage. In JBoss AS 7 the majority of our modules are identified by the API they implement. To give a simple example, there is a module called org.apache.commons.logging which implements the Apache Commons Logging API - however, this module is essentially just an alias for the org.slf4j.jcl-over-slf4j module which emulates JCL using slf4j's backend. In this way you can provide a reasonable level of decoupling without resorting to complex OSGi-style resolution semantics.

 
28. Apr 2011, 14:17 CET | Link

Sorry for resurrecting this thread but I've been looking around trying to find documentation on how to use JBoss Modules... is there any?

 
06. May 2011, 22:25 CET | Link

Yeah I'm putting 30 minutes per day into the user manual which is located on our new docs authoring site.

 
19. Jun 2012, 23:41 CET | Link
borisha

documentation for modules is in really bad shape.. a lot of empty sections

13. Sep 2012, 17:33 CET | Link

I was wondering if you can use JBossModules as part of a web application running inside standalone tomcat, I mean not a tomcat embedded inside JBoss AS.

From what I've seen you just need to discover how to do it, but seems its possible.

I was not able to find nothing related to it, in docs or in the web.

I will be wonderful to get a basic sample on how to do something like it, just want to have a basic startup skeleton son I can get into Jboss Modules itself once basic startup things are done.

I guess what I need basically are these kind of things

  • How to start tomcat (if it really needs a particular way of doing so)
  • How to initialize module framework. Should the module framework be configured at tomcat level, or perhaps on each webapp
  • Perhaps how to configure/set dependencies on each web application so they can use the module framework
  • Anything else you might thing useful.

Thanks very much in advance, tonio

 
08. Feb 2013, 14:21 CET | Link
kosalads

Hi David,

I hope you could help me on this. I have an .ear with multiple dependencies and external jars. In Jboss 6 I just added in the lib and it works fine. But with jboss AS 7 I need to create those as modules and add the module.xml file for each library. However, even when I did that im getting errors as I need to add the dependency for those external libraries.If im to do this then it takes more time and I dont this it is practical to do. So what is the best way to handle this situ and any suggestion appreciated.

 
24. Jun 2014, 12:58 CET | Link

There are few basic parameters like minimum deposit required to open an account, maximum leverage offered, spread of major currencies, commissions charged, number of pairs offered, and the availability of operating a mini account which we must consider while selecting our broker and also forex brokers comparison Top Forex brokers today are online Forex companies with trading platforms offering broad functionality and stable access all business week. Practically top forex brokers provide traders with online Forex trading systems, web platforms, analysis tools, Forex charts and leverage

Post Comment