Discussion: #LazyConfigurationAndInstantiation

[mark.reinhold at oracle.com]

2016/7/13 10:39:42 -0700, david.lloyd at redhat.com:
> On 07/13/2016 09:31 AM, mark.reinhold at oracle.com wrote:
>> Reference: http://openjdk.java.net/projects/jigsaw/spec/issues/#LazyConfigurationAndInstantiation
>> 
>> 2016/3/11 13:55:56 -0800, david.lloyd at redhat.com:
>>> ...
>>>                                                       Another potenti
>>> issue is requiring that all modules be present, though this is more
>>> closely related to #MutableConfigurations now I think; I suspect this
>>> issue could be mitigated with an acceptable solution to that issue.
>> 
>> As I wrote in my reply re. #MutableConfigurations [2], I think this
>> approach is at odds with our goal to provide reliable configuration.
> 
> I disagree.  "Reliable" is only defined in the agreed-upon requirements 
> by stipulating that modules may have dependence relationships which are 
> declared.

Fair enough.  I'll restate my position to say that #MutableConfigurations
is at odds with the way in which the present design provides reliable
configuration.

>            I interpreted that goal simply as an explicit rejection of 
> various poorly-defined customized class loader behaviors, and a move 
> towards clearer and more predictable behavior.  By my interpretation and 
> experience, I consider, for example, the ability to change the explicit 
> dependence relationships to still be "reliable" as long as the effects 
> of doing so are well-defined, just as I consider the behavior of lazy 
> class loading to be "reliable" in that it is well-defined and 
> predictable, and has rules which make sense (referring to the way that 
> classes are loaded, resolved, and initialized in separate phases, which 
> allows for lazy on-demand-only progression through those phases but also 
> allows for almost completely arbitrary interconnection of classes, while 
> remaining basically predictable).

These are all reasonable interpretations of the high-level goal of
reliable configuration.

I make no claim that the present design is the only way to achieve
reliable configuration, for some reasonable definition of "reliable".
It is, however, one way to achieve it.

It might be possible to support reliable configuration, and to satisfy
all of our other agreed requirements, with a design that configures and
instantiates layers lazily rather than eagerly -- though I'm skeptical.
At any rate, that is not the design that we have today.

> The first time that "reliable" is specified in terms of concrete 
> behavior is in the SOTMS document, and these issues are being raised 
> exactly against the state of the module system, so I think that this 
> issue as well as #MutableConfigurations serve to directly challenge the 
> validity of the definition of "reliable" which is used by the proposed 
> implementation, rather than being invalid due to the presumed validity 
> of that definition (which was not agreed upon by the EG).

The present design is meant to satisfy the requirements previously agreed
by this EG.  Those requirements do not include any constraints along the
lines of #MutableConfigurations or #LazyConfigurationAndInstantiation.
Your desire for these properties now is no basis for a claim that the
design is unacceptable with respect to previous agreements of the EG.

> Even the JSR definition (which I acknowledge is quite out of date at 
> this point) states that OSGi does address the problem of "reliable" 
> configuration, despite the fact that the OSGi solution allows for 
> dynamic loading and relinking.  This is contrary to the definition in 
> the SOTMS, and also despite the fact that Jigsaw's more strict 
> interpretation of this actually invalidates those behaviors of OSGi, 
> were OSGi to try to merge the bundle concept with the Jigsaw module 
> concept somehow.

The present design invalidates nothing.  OSGi can continue to operate
just as it does today.  There is no agreed requirement to support a
hypothetical future merge of OSGi's bundle concept with the platform's
module concept, which is a research project that is clearly outside
the scope of this JSR [1].

- Mark


[1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-February/000019.html