Felipe Gaucho's Blog

JSR-277: Super JAR and the three kinds of Hell.

Michal Cierniak and Stanley Ho introduced the JRS-277 (Java Module System) talking about three kinds of hell: Classpath Hell: Where are your classes and libraries? Why different IDEs use different folders? Does it matter? JAR Hell: How to deliver different libraries in only one JAR? Extension Hell: Remember that nightmare when a different version of a class was being loaded from an unexpected JAR?

Well known problems like How to deliver applications in only one JAR and the version control and management of dependencies between different modules of an application motivated these researchers to propose something better for the next generation: a Super JAR mechanism that allows developers to simplify development and deployment processes. As you will read in this entry, Maven seems to be quite similar to this new specification, but there are some enhancements in parts were Maven and other integrator mechanisms failed in the past. It is a new idea based on old problems, so the solution is a collection of best practices and learned lessons, including an elegant conflict resolution that sometimes reminds us of operational systems algorithms. During JavaOne, most part of the session was consumed by explanations about the conflict scenarios and the strategies the authors were proposing to avoid them - tricky but also very interesting.

What is a Module?

A module is a set of artifacts that can be executed as an application or artifacts that can be part of an application - including libraries, classes, files and any other resource required during the runtime. From the specification:

	A Java module is a unit of encapsulation. It is generally written
        as a development module	in a programming language in the Java platform,
        and is ultimately compiled into meta data and packaged together
        with classes and other resources as a deployment module.

The goal of the new specification is a first class modularity:

• Versioning scheme: the nowadays JAR format does not support versioning, what means the correct version of the libraries should be controlled by developers and deployment engineers. Usually we adopt name conventions to solve conflicts and to alert the users about the library version, but we all know this is error prone. The authors suggested to include some versioning scheme with runtime validation process, solving the first hell.
• New distribution format (JAM): JAM comes from Java Module, and it is based on the JAR file format plus some advantages:
  • Signed JAM files: the signing and signature verification for a JAM file are identical to those for the JAR file format in the Java SE platform. A JAM file can be signed and verified using, e.g., the standard jarsigner tool from the Java SE SDK.
  • Compressed JAM files (Pack200): Pack200 is a hyper-compression scheme for the JAR file format, and it is defined in JSR-200. The JAM file format is based on the JAR file format, hence developers may use Pack200 to further compress a module archive (i.e. a JAM file) for distribution.
  • Fine grained security in JSE 7: they are looking to use some Java 7 proposed features to enhance the security level of the JAM files, including the ability to reduce the visibility of some resources through manifest configuration. It is not included in the current specification, but is a good outlook.
• Repositories: this part is Maven-like, but with some new features like repositories hierarchy. Several repositories (bootstrap, global, application, local, URL) can be accessed during the runtime to resources retrieval, and some naming and versioning conflicts can occur during this process. The resolution of these issues is an important part of the JSR-277, but I invite you to check the early draft about that because it is not something I can summarize in few lines of a blog :)
• Runtime support: a great advantage of the Module System over Maven and other integrators is the Runtime support. Proposed to be part of the JRE, the new mechanism will receive a privileged treatment during the startup of applications, and all its features will be executed by the virtual machine itself instead of a third-party code. Runtime will include validation of modules, a wonderful feature that brings the Java developers full control about which resource and which module will really be used by their applications.

A lot of information for a simple blog, but the subject is fascinating and I guess the new Module System can give us a much better control over our deployment tasks in a near future. I strongly suggest you to visit the specification download page, read the early draft and start preparing to change your configuration procedures in the next year.

Comments

• Thanks for the info and especially the One-JAR link. Sadly for JAMs, though, if it's only available bundled with the JRE, then it won't be available for general use in applications until Java 7 ships on all major platforms. That's years and years away. That should keep OSGi and Maven strong meanwhile. (And I'll hope to see some integration between all these systems eventually.)

  Posted by: tompalmer on May 16, 2007 at 11:23 AM

• This is fantastic, but there are more problems that need thinking about:
  Where do you put the jnlp file, in the JAM file or will it be floating around separate too?

  Will WinZip & friends steal the .JAM extension association like they do for .JAR files? If they do this, JAM files will not be single-click launchable so they'll be useless just like JAR files.

  Why can't we distribute an exe file?! For computers with no Java, the JAM file will do nothing since there will be no file association (except maybe with WinZip or WinRare :( )

  Thanks for highlighting this burning issue, I just think there's a lot more to it than having a single JAR.

  Keith

  Posted by: commanderkeith on May 16, 2007 at 05:35 PM

• You failed to mention the 4th type of hell, more complicated deployment descriptors written in XML.

  I would also strongly suggest that people visit the specification because I'm worried that we may miss on this one and end up with a JEE deployment hell in the JSE. I maybe wrong and may have misunderstood what Stanley Ho and others have been saying. However Stanley hasn't given me a warm and fuzzy feeling when ever he's entertained my questions. And I have high regards for Stanley's cleverness.

  Kind regards,
  Kirk Pepperdine

  Posted by: kcpeppe on May 17, 2007 at 01:05 AM

• One major concern I have about this JSR is ease of use. OSGi and friends are all very labor intensive. The JSR committee should make this as easy to use and automated as possible; if it risks not making it into Java7 so be it.

  We don't want to end up with yet another half-baked solution as Generics. Ease of use, ad infinitum.

  Gili

  Posted by: cowwoc on May 17, 2007 at 09:59 AM

• "Why can't we distribute an exe file" sigh... When you succeed in creating a platform independent executable format that will run without a special runtime on any hardware architecture and any operating system maybe that will become possible. Until then, don't try to force everyone into your narrow world of single platform deployment scenarios.
  "Will WinZip & friends steal the .JAM extension association like they do for .JAR files" That's got nothing to do with the file format, only with the way people use it. By default Winzip does NOT associate itself with jar files, you have to explicitly tell Windows to do that. If you do, that's your problem.
  

  Posted by: jwenting on May 17, 2007 at 10:17 PM

• Please don't call them JAM files; almost anything is better. JAM doesn't go with coffee anyway ;) Please, don't make me try to sell my users on inedible JAM files!

  May I suggest Java Loadable Module (JLM) as one neutral alternative, or Java Modules (or Modularized) Jar (JMJ) as both infinitely preferable and might even call down some help from Heaven. We all need that.

  p.s. I'm sorry I missed your packaging session at JavaOne, but I promise to get to it ASAP, when it's posted on the JavaOne site, as it is very, very important to me.

  Posted by: mike__rainville on May 17, 2007 at 11:02 PM

• ehehe, JAM? ok, I suppose it is a bad word in English, but for all countries it means nothing. Good issue for the authors.

  Posted by: felipegaucho on May 17, 2007 at 11:48 PM

• Hi Kirk,
  If I understand your concern correctly, I think it is about whether JSR 277 would require developers to use crufty XML file as module metadata. The good news is that the current design expects tight integration between JSR 277 and JSR 294 (i.e. superpackage), and it allows us to move the module information from crufty XML files into the Java language itself using the superpackage construct and annotations. This is kind of like replacing Java EE 1.4 deployment descriptors with in-code annotations in Java EE 5, and it should make it very simple and easy for development and deployment.
  - Stanley
  

  Posted by: stanleyh on May 22, 2007 at 02:34 AM

• Is it possible to have a jam that support the stream based java class loading.
  For this I give an exampleIf I have an Applet(1.class) in package(app) deal with 2 classes(2.class, 3.class) in package (app2)
  Then JVM should first be able to load the 1.class from the jam file and then start render it ,
  in the rendering point if it requires to call a method on 2.class and it is not loaded at that
  time then JVM should load the 2.class and show a golden progress line in TOP CORNER of applet and
  temperarily stop rendering, after it loads the 2.class it should just start working normally,
  after sometime if the 2.class need to call a method in the 3.class and it also not available
  at that time then once more we should show a loading bar and wait until the 3.class loads.
  This is the way we can have the good user experience.

  If this is not possible with jam then why not you introduce a filetype called jab(JavaArchive for Browser).

  The jab works like below

  As said above app(Folder) contains 1.class and app2(Folder). app2(Folder) contains 2.class and 3.class.

  Then the jab format should be like:

  
  Content of 1.class in zipped format to reduce the size
  
  Content of 1.class in zipped format to reduce the size
  Content of 1.class in zipped format to reduce the size
  

  Here the jab packer should be smart enougth to place the class files according to usage tree.

  In this format in the first you will encounter the main class in the start if archive ,
  so you can start rendering the applet. This is the way we can avoid the time waited by the
  user until all the jar files needed are loaderd into JVM.

  If any one wants to have brought round the view pleae feel free to mail me
  iamdvr@yahoo.com OR desu.venkateswara@yahoo.co.in

  Posted by: vr9_desu on July 10, 2007 at 05:35 AM

• This is format of jab file ::

  <FOLDER name="app">
  <FILE name="1.class">Content of 1.class in zipped format to reduce the size</FILE>
  <FOLDER name="app2">
  <FILE name="1.class">Content of 1.class in zipped format to reduce the size</FILE>
  <FILE name="1.class">Content of 1.class in zipped format to reduce the size</FILE>
  </FOLDER>
  </FOLDER>

  Posted by: vr9_desu on July 10, 2007 at 05:37 AM

• Is it possible to have a jam that support the stream based java class loading.
  For this I give an example If I have an Applet(1.class) in package(app) deal with 2 classes(2.class, 3.class) in package (app2)
  Then JVM should first be able to load the 1.class from the jam file and then start render it ,
  in the rendering point if it requires to call a method on 2.class and it is not loaded at that
  time then JVM should load the 2.class and show a golden progress line in TOP CORNER of applet and
  temperarily stop rendering, after it loads the 2.class it should just start working normally,
  after sometime if the 2.class need to call a method in the 3.class and it also not available
  at that time then once more we should show a loading bar and wait until the 3.class loads.
  This is the way we can have the good user experience.

  If this is not possible with jam then why not you introduce a filetype called jab(JavaArchive for Browser).

  The jab works like below

  As said above app(Folder) contains 1.class and app2(Folder). app2(Folder) contains 2.class and 3.class.

  Then the jab format should be like

  <FOLDER name="app">
  <FILE name="1.class">Content of 1.class in zipped format to reduce the size</FILE>
  <FOLDER name="app2">
  <FILE name="1.class">Content of 1.class in zipped format to reduce the size</FILE>
  <FILE name="1.class">Content of 1.class in zipped format to reduce the size</FILE>
  </FOLDER>
  </FOLDER>

  Here the jab packer should be smart enougth to place the class files according to usage tree.

  In this format in the first you will encounter the main class in the start if archive ,
  so you can start rendering the applet. This is the way we can avoid the time waited by the
  user until all the jar files needed are loaderd into JVM.

  If any one wants to have brought round the view pleae feel free to mail me
  iamdvr@yahoo.com OR desu.venkateswara@yahoo.co.in

  ::::::::::::::::::::::::::::::::::::

  
  :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

  Posted by: vr9_desu on July 10, 2007 at 06:19 AM

• The subject of a very wonderful and distinct
  I thank you for continuing excellence
  Thank you

  =========================================================================

  ليبيا
  شباب ليبيا
  libya
  منتديات
  منتديات ليبية
  غرائب وحقائق
  أحاديث شريفة
  برامج اسلامية للجوال
  مفاتيح الديجيتل
  الشيرنج
  الرسيفرات
  كتب إسلامية
  خلفيات للموبيل
  الشعر الشعبي
  الصحة والطب
  طب اسنان
  كتب طب اسنان مجانية
  برامج طبية
  تعلم الإنكليزية
  اللغة الفرنسية
  طب الإعشاب
  الخواطرالادبية
  الازياء والمكياج
  تعليم الطبخ
  الاثاث الحديث
  مقاطع كرة قدم
  المصارعه الحرة
  اهداف كوره
  الفوتوشوب
  اروع البرامج
  الدوري الليبي
  خلفيات رياضية
  المصارعة
  كورة عربية
  كرة قدم عالمية
  الدوري الإيطالي
  الدوري الاسباني
  الدوري الإنجليزي
  صور المشاهير
  انواع الحلويات
  افلام كوميدية
  احدث الافلام
  افلام
  التقنية
  تحميل افلام
  برامج
  اخر برامج الجوال
  kaspersky
  أفلام كرتون عربية
  برامج برامج كمبيوتر
  برامج حماية
  برامج اختراق
  برامج صوت
  برامج تحميل برامج احدث البرامج
  محادثة
  خلفيات الطبيعة
  برامج مبايل للتحميل
  اخبار الفن
  احدث الافلام للتحميل
  تحميل افلام رعب
  ترجمةأفلام
  الكامات
  برامج جوال
  برامج محاسبة
  برامج
  kasper
  games
  برامج
  برامج
  انترنت
  برامج صوتية
  شبكات الحاسوب
  خلفيات للويندوز
  تطويرالمواقع
  العاب
  العاب الفيديو
  games
  شفرات
  برامج مسنجر
  خلفيات شاشة
  صور ترحيبيه
  الفوتوشوب
  خلفيات طبيعة
  تطويرالمواقع
  الفوتوشوب
  مقاطع البلوتوت
  مسجات ليبية
  خلفيات
  الفلاش
  التصميم الثلاثي
  برامج الجوال
  العاب الجوال
  فيديو كليب
  مسجات
  ترددات ستالايت
  نغمات
  

  Posted by: libyan on May 30, 2008 at 02:53 PM

This work is licensed under a Creative Commons License.