Thanks for posting this Mark! Some quick feedback after going through: http://openjdk.java.net/projects/jigsaw/goals-reqs/03
When reading this part: > *"We do not propose to modularize the Java Language Specification, the > Java Virtual Machine Specification, or their implementations in the JDK. > The Java programming language is, itself, indivisible. A particular Java > Virtual Machine implementation may have its own internal modular structure, > but we do not see a compelling need to expose such low-level details in the > form of modules; doing so would, moreover, be very difficult."* This inevitably leads to the conclusion that the introduction of modules, as defined in the document, will have no (or little?) runtime impact, when thinking of aspects like (1) lifecycle management - install/uninstall/start/stop/load/unload; (2) garbage collection and freeing up memory; (3) runtime resource sharing and quotas. While stating that is ok when looking from the JDK perspective - it indeed is a problem when thinking about larger constructs in the Java EE world. : > > *Non-requirement:**Run-time replacement — It is not necessary to be able > to replace a JDK module with a different version of that module after a > run-time image has been invoked.* As of today - a Java EE server has no means to reliably stop, unload and bring in a new version of an application (regardless whether it brings dynamic native libraries packaged in it or not). Despite of the explicit (stop) intent expressed by the administrator - the corresponding Java EE server can at best eliminate its own references to the application classes/objects and release its classloader, hoping that things will get cleaned up. Whether it will really get garbage-collected and the memory freed - depends solely on the good will and skills of the app developer and how clean the implementation of the application is. In case it has left any of those: (1) unregistered resources (loggers being the most common suspects), (2) unclosed zlib stream handlers <http://kohsuke.org/2011/11/04/quiz-answer-memory-leak-in-java/>, (3) objects with finalizers in a long finalizer queue - the app loader will keep on hanging in. This on its turn will lead to clashes on different types of resources, including (but not limited to) (1) read-only files which can't be written while starting the new version of the app, (2) unclosed connections, (3) inconsistent log behavior (influenced by the old loggers still being registered), etc. This leaves little options for maneuvering to application server providers, different than restarting the app server process. That's (to date) is the only reliable way to ensure that a certain application has been properly unloaded, regardless how buggy its implementation is. It would be great to have a more clear statement in the document (even in the case that it falls in the "non requirements" section) to clarify whether Jigsaw in Java 9 will have any impact/effect on the above-described scenario. I certainly understand that in order to offer a way for Java EE application servers to reliably unload/reload modules/applications at runtime - this will most probably require an extension of the Java Language Specification, which as far as I get it - is currently out of scope for the Jigsaw project. Best regards, Krassi On Wed, Jul 2, 2014 at 11:21 PM, Neil Bartlett <[email protected]> wrote: > Mark, > > Perhaps then it should be a stated goal...? > > Regardless, David’s point does seems necessary to support goal number four > (“Make it easier for developers to construct and maintain libraries and > large applications, for both the Java SE and EE Platforms”) in that it > would enable interoperability with the existing module system that is being > used to construct and maintain libraries and large applications. > > The previous draft requirements dated 19 April 2011 (then called “Draft > 12”, but now we are on Draft 3?) stated the following with respect to OSGi: > “It must be demonstrated by prototype to be feasible to modify an OSGi > micro-kernel such that OSGi bundles running in that kernel can depend upon > Java modules. The kernel must be able to load Java modules directly and > resolve them using its own resolver, except for core system modules. Core > system modules can only be loaded using the module system’s reification > API.” > > Can you confirm that this requirement will still apply in the new phase, > or has it been deliberately dropped? > > Regards, > Neil > > > On 2 July 2014 at 21:57:22, [email protected] ( > [email protected]) wrote: > > 2014/7/2 5:22 -0700, [email protected]: > > One thing that I think should also be a requirement is that the module > > metadata should be in an easily extensible format so that tools and > > other module systems such as OSGi can augment it with additional > > metadata. > > That's not clearly necessary in order to achieve the stated goals, > so I don't think it's a requirement. > > It could, however, be a reasonable design decision in the service > of some of the requirements related to tooling and migration. > > - Mark >
