Stanley Ho's Blog

JSR 277: Java Module System

Sun has recently submitted the Java Module System JSR to revise the Java packaging architecture. This is an area that has been long overdue for an overhaul, and the goal is to make it easier to bundle, distribute, and deploy Java applications and Java extensions (aka optional packages).

Comments

• Hi Stanley--I'd be interested in seeing a comparison between this and other repository systems for Java like Maven and Ivy, and on the other hand between the Java Module System (unfortunately, abbreviated JMS) and the .Net deployment system. I'm sure you guys have at least touched on that in your internal discussions, want to fill us in on how this differs or is similar? Cheers Patrick

  Posted by: pdoubleya on June 15, 2005 at 03:19 AM

• Hi Stanley,
  I would strongly suggest you to have a look at how SAP solves this problem with the concept of Development Components(DCs).
  www.sdn.sap.com could be the right place to go/ask questions about that. I'm nearly sure they'd like to collaborate...
  Cheers, Stepan.

  Posted by: ssamarin on June 16, 2005 at 01:05 AM

• Last 2 enteries in this blog seem to me like Sun is looking for exotic new features.

  Why not fix bugs? http://lopica.sourceforge.net/faq.html

  .V

  Posted by: netsql on June 16, 2005 at 02:55 PM

• I don't know if I've read correctly , but I beleive that you intent to make a "bootloader" a la OSGi. I just want to share my experience hoping that it might be useful.

  Weak point of OSGi:
  I'm curently using an OSGi framework and I don't like to handcode that many information in the bundle's manifest.
  Each time that I import a class from another bundle (a think that I'm not always consious while coding because of the auto import feature of modern IDEs) I have to update the manifest. When you work on 30 bundles or more that starts to be a problem. The import / export header should be automatically generated.

  Wishes:
  I wish that the loader could load modules in parallele (taking into account module dependencies) just like Mac OS X does at startup. This way startup could be faster, optimized.

  I wish that I could visualize the dependency map of the modules. Right now I have to be careful to create/update the documentation of the map. I don't like that because the documentation is disconnected from the real think, so if I'm not careful it could potentially be wrong ... and manually checking all those relationships is a pain.

  I also hope that special attention is put on code update, starting and stoping of modules. A satisfactory answer has to be given to this case: Imagine a system that has 2 modules A and B. B needs A to work. Let's say I want to update the code of module A. The best scenario would be to update the code without restarting B (if that is possible, for example, if method signatures used by B haven't changed).

  If you have to update serveral modules it would be nice not to have to worry for the update order (I would just send the modules and say update code).

  
  Please automate the processes that can be automatically discovered.
  

  Posted by: urddd on June 19, 2005 at 09:31 AM

• Hi pdoubleya,

  Comparing repository features between different systems is like comparing apple and orange. Each repository may provide different set of features due to the design of the overall system. You really have to analyize each system as a whole and compare. I will consider this as a future blog topic if people are interested.

  - Stanley

  Posted by: stanleyh on June 20, 2005 at 12:56 AM

• Hi urddd,

  Thanks for sharing your experience.

  The goal of this JSR is to address the distribution and deployment needs of applications and extensions. It includes many components, such as a distribution format, a versioning scheme, a repository, runtime support and tools support as described in section 2.1 of the JSR.

  Our intent is to make module a first-class feature in the JVM, with potential language support. OSGi certainly have some good idea (e.g. versioning scheme) that we can learn from, and the expert group will certainly take OSGi as one of the inputs among other existing architectures to come up with a best overall solution.

  I agreed with your points on the Manifest hell. The current JAR manifest is unstructured and it is very hard for developers and tools to update it. Specifying dependency manually could be a very painful process, and we hope that the tools support in this JSR could automated most of these steps. I believe it is important to keep developers to focus on what they do best, i.e. design and coding, instead of distracting them in tedious details of packaging, and this is one of the areas this JSR will attempt to address.

  - Stanley
  

  Posted by: stanleyh on June 20, 2005 at 12:58 AM

This work is licensed under a Creative Commons License.