* Increase performance. The VM download size can be made smaller
Download size decrease is not a factor: end users (other than applets) don’t download the JRE.

, and startup time should improve because for small programs (say HelloWorld) unnecessary classes don’t have to be loaded at all.

unnecessary classes aren’t loaded at all today by the classloader.

Mark showed how he could run HelloWorld by only using 2 modules listed by the new jmod command; jdk.base@7-ea and jdk.boot@7-ea.

Did Mark show that there were in fact, any less classes loaded using the module system? If so, how could that be? The classloader is supposed to only load classes that are actually used.

* Enable native integration for installing modules.
As others have pointed out, this is an inherently bad idea, and goes against the cross-platform nature of Java. The current “bundle all needed jars with each app” approach is the better way.

Also, Java being a cross-platform language, introducing platform-dependent package formats is the wrong way to go.
The best solution would be to have cross-platform package format, which could be mapped to a native package format by the Java installation at the time of the import of the package (if required at all!). However, this is an under-the-hood process that the package developer should not have to deal with.

Today, many applications are built upon (or are migrating to) OSGI. They won’t abandon this platform once Java 7 comes out. As Augusto said, this is likely to repeat the java.util.logging disaster.

Please, for the sake of the language and the people who are using it, get yourself together at JSR 294 and
- build upon proven and mature technology such as OSGI
- improve and extend it where neccessary

I understand, that Sun is looking for some way that allows them to modularize the core java components, in such a way that the VM itself can benefit from it.

Then, there is the whole native packaging side of things, which – so far – seems pretty unrelated from a technical point of view. The whole idea of native packaging is both interesting and frightening at the same time, depending on how it is carried out. Having an easy way to install java apps in a linux distribution sounds great to me as a Debian user. Packaging tools would be nice, but they could, for example be developed in cooperation with icedTead – I don’t see why they should go into the JDK. It should definitely not be necessary to generate “installable binaries” for each target platform, when deploying java code.
In my opinion, one of the major reasons one point of failure for java apps on the desktops was that they used .jar as extension for “executable jar files”. Why not have the convention of .javaapp files which are nothing but renamed executable .jars with an icon in them that are executed automatically through a Java-specific shell extension? This would make a LOAD of windows-specific java starter/installer programs go away over time. This does not say, that either installation support or a module system are not useful, but sometimes, a LITTLE more integration can make a big difference, without having to re-invent the universe.

Then, and that is the point that confuses me most, Mark Reinhold claimed that one of the possible future advantages of their module is that there is an act of installation which would, for example allow to pre-compile code to improve startup times.
To me, this raises a lot of questions
- what is preventing Sun from pre-compiling their own Java code before download or during installation? No public plattform-specific installation mechanism is required for that. Was this not mainly about JVM startup times for Desktop and Web Apps?
- what is preventing the VM to cache compiled versions of code, once it has been run for the first time? Especially with module metadata, the VM could identify recurring uses of the same module and re-use previously compiled code. This would move part of the installation cost to the first usage of an application, but after that, startup times could be automatically improved by some VM trickery, based on module support in the Java runtime, yet without an explicit installation step.
- Downloaded code cannot be pre-compiled during installation anyway. Was not a lot of this motivated by wanting to speed up JavaFX applications? These will run without being installed before anyway.
- what does “installation” actually mean to Sun? Do they indeed have something like a global assembly cache in mind? If so, will its behavior be specified so that it can be provided by other VM implenentations? How will a package get into it? Only through Sun- and OS-specific installation procedures?

Whatever tricks the Sun’s Java implementation does behind the scenes to perform its job does not matter as long as it helps performance and is an internal implementation detail. But if Sun should create deployment mechanisms that are specific to their own VM, then this would be rather dangerous, as it would put alternative implementations into disadvantage. What has been going on on the spec-side with Apache Harmony is sad enough, so I really hope that Sun is not adding mechanisms that hinder interoperability with their implementation in an area as important as deployment. (Btw: I have not used Harmony at all so far and I am not associated with any of the various “camps”, but as a Java developer I care about the long-term openness and interoperability of Java [as a plattform, not just of Sun's version of it]).

Somehow, Sun’s decision to “do their own thing” with Jigsaw reminds me of what could be described as an extension of the Applet livecycle with the dragable Applets that were introduced during the 6u10 “maintainance” release, or their added support for JNLP-Applets. Shouldn’t this stuff have been spec’ed? Yes this did not add publically callable APIs in java.*-Packages, so I guess it does not violate the letter of the JCP, but nonetheless, these are proprietary extensions in inportant areas of the platform and therefore make me rather nervous, despite their technical merit.

Sorry for the very long comment. Overall, I like what Sun is trying to _achieve_ and I understand that they grow somewhat impatient. Nonetheless, it’s important that they strive to keep their implementation as interoperable as possile.

When talking about OSGi, Alex Buckley brought up some issue somebody had (I think with the JDK’s corba packages) while using OSGi but I don’t remember main problem in the blog post or what blog it was. It was hard to hear, all I remember is that he read it out loud and said something like “this is the type of thing we are trying/want to avoid”. If anybody knows what this blog post was or what that part of the discussion was about please let me know.

As for Sun dropping the ball on another modular framework, which one are you referring to, the Netbeans Module system?

Like everything, it has its pros and cons. I see some of the benefits of integrating with the native package management of a system, but it would be really nice to get the complete picture to feel more comfortable with the concept. Right now, nobody really knows how this is going to work in Windows (or Apple), and then there’s even more details like what if I don’t want to update modules at the system level but just for my application?

The native packaging issues related to Jigsaw could have been a dedicated technical track by themselves. I would hope more details and ideas come out soon just to see if people are comfortable with this or not.

@Peter

Thanks for your reply, I’ll try to follow up in the comments section of your blog.