Project Jigsaw: Phase Two

[Krasimir Semerdzhiev]

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 <njbartlett at gmail.com> 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, mark.reinhold at oracle.com (
> mark.reinhold at oracle.com) wrote:
>
> 2014/7/2 5:22 -0700, david.bosschaert at gmail.com:
> > 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
>