I attended the first Jigsaw session at JavaOne today where Mark Reinhold presented the latest on Jigsaw. After what appeared to be the end of the presentation, Mark continued on and began discussing why OSGi is wrong for using packages as the primary unit import and export between modules and why Jigsaw is right for requiring (aka. importing) modules (but apparently, and non-symmetrically, exporting packages and types). Mark made several strange arguments.
He found the idea of a resolver matching package importers up to package exports (essentially a broker pattern where the resolver acts as the broker) to be bad/complicated/etc. He prefers the developer to effectively be the "resolver" and declare the specific modules to be imported. This removes an important level of indirection between the thing being provided and the artifact providing it. This is like saying, "Don't use interfaces, use concrete implementation types," because we don't want to have to figure out how to map the use of the interface onto a concrete implementation type.
Mark also stated that requiring modules mapped well onto native package managers (e.g. rpm, apt) while importing package provided for no simple mapping. So therefore requiring modules is the way to go. It seems rather sad to me that the design of modules for Java 8 is being driven by the capabilities of native package managers designed in the 1990s for native code. Shouldn't the design of a module system for Java be driven by the capabilities and attributes of Java?
Subscribe to:
Post Comments (Atom)
4 comments:
Mark's second point is not just sad but wrong, at least in the case of RPM, which does have a system of capabilities and requirements, similar to OSGi/OBR.
I'm not so familiar with Debian, though it does seem less flexible. Perhaps Mark is going for a lowest-common-denominator approach... but even in that case he is not being consistent because the real lowest common denominator is the complete absence of package management on Windows.
Also: why should Java be the only "managed" environment that shoehorns its packaging into poorly-fitting native managers? Ruby has Gems. Python has Eggs. Perl has PPM. Java has OSGi Bundles.
Sure, build a native package for the JRE plus an OSGi framework and minimal provisioning agent, based on either OBR or p2. Then provision the rest of the platform the way nature intended.
This is very sad and worrying. Do you think you can post a link to the presentation slides if/when you get them?
Maybe I am missing something, but I don't see what platform package managers have to do with Java modularity (nor why they should have). Isn't Java supposed to be platform independent anymore?
Post a Comment