Project Jigsaw: Phase Two

Alan Bateman Alan.Bateman at oracle.com
Mon Jul 7 13:43:29 UTC 2014


On 06/07/2014 23:59, Krasimir Semerdzhiev wrote:
> :
>
> 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. :
I'm not sure what it means to modularize the Java Language or Virtual 
Machine specifications (except perhaps today's example of the CLDC 
configuration in Java ME where they subset). Much of the item that 
you've picked out is about not requiring a VM implementation to have a 
modular structure, say being able to compile in or leave out specific 
features, specific garbage collectors or runtime compilers for example.

In any case, I've no doubt that there will be a significant runtime 
element to this project, particularly due to the requirement to strongly 
encapsulate internal APIs.

The issues with references preventing or delaying objects from being 
GC'ed or delaying class unloading is indeed a challenge. The section on 
"Dynamic configuration" is the EE case and I don't think would be very 
useful if weren't possible for applications to terminate and for 
everything that they used to be GC and be unloaded some time later. As 
to forcibly terminating applications (or application threads) then there 
are long standing good reasons why there isn't supported. I could 
imagine a multi-tenant or a VM project supporting isolation wanting to 
take on such issues.

-Alan.


More information about the jigsaw-dev mailing list