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.
