Huh? JDK7 is not going to be modularized. Not with Jigsaw, not with OSGi. As far as I understand, the OSGi vs. Jigsaw dynamic hasn't changed in the slightest; OSGi is not suitable (on one hand too complicated and in other areas not complicated enough) to properly modularize the JDK, for a number of reasons*, and as a result a different mechanism has been designed to modularize the JDK, called Jigsaw. The choice has been to make this mechanism available to all java programmers.
* (I'm just recalling what has been said by i.e. Mark Reinhold. Mistakes here are either me misrecollecting, or misunderstanding Mark): 1) To remain backwards compatible, split packages have to be supported well. OSGi doesn't support them well, and many OSGi tools apparently don't support them at all. 2) To modularize the JVM from the ground up, modules have to be supported at the core level - you can't modularize i.e. java.util.List if the modularization engine needs java.util.List in the classpath to operate. 3) As part of the 'java is open source' move, it would be nice if you could install java modules using your system's local packaging system, such as apt on debian and ubuntu (this takes the form of the jigsaw packager app being able to spit out .deb files, for example). Unfortunately, the OSGi versioning scheme is not compatible with these. Also, many existing versioning schemes used by various libraries isn't compatible with OSGi either, and jigsaw intends to neither force developers to switch schemes, nor to operate with a dual versioning scheme, again leading to the much more loosely defined versioning scheme of jigsaw. Note that the jigsaw umbrella actually involves 3 mostly separate projects: A) Modularize the JVM. This involves creating text files listing classes that belong to a single modular unit, removing dependencies between such modules that shouldn't be there, and coming up with a hierarchical view of modules + dependencies. This is module system agnostic. Heck, it doesn't even need a module system. B) Add language support for the 'module' keyword, and to a lesser extent, to a java-esque syntax (also stored in .java files) for defining the properties of modules. C) Build support for modularization into the C core, and write tools that can produce and introspect modules, including the ability to spit out alternative packaging formats, such as debs, and inventing a new package format that can lead to more efficient processing of class files than the current jar file format offers. This format will be opaque (will NOT be defined as following the zip standard), in order to allow easier revving of the format. On Oct 12, 1:50 am, Fabrizio Giudici <[email protected]> wrote: > On 10/12/10 01:38 , Eric Newcomer wrote: > > > Presumably this means they have also agreed on OSGi? > > Well, GlassFish went already OSGi, NetBeans followed since the last Sun > times... At the past J1, I was surprised to see jigsaw postponed to Java > 8: I understood that, once one accepted the jigsaw model, there weren't > specific issues to solve. I don't know whether what I'm going to say > makes technically sense (I recall some Gosling debate about the fact > that OSGi wouldn't fit at JRE level - really I don't know), but I > suspect that they took the time to eventually drive the modularization > thing to another direction. > > -- > Fabrizio Giudici - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > java.net/blog/fabriziogiudici -www.tidalwave.it/people > [email protected] -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
