Discussion: #LazyConfigurationAndInstantiation

[David M. Lloyd]

On 07/19/2016 04:11 PM, mark.reinhold at oracle.com wrote:
> 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.

Indeed, and this is why these issues have been raised: the current 
design is not acceptable as-is.

>>            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.

I think it ought to be discussed.  It's my estimation that many of the 
parameters of the current design are in excess of the agreed-upon 
requirements and can be rolled back to an extent without compromising 
what was already agreed upon.

> At any rate, that is not the design that we have today.

Agreed, and that is why we have raised these issues.

>> 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.

I can't agree with this logic: it could just as easily be said that 
various behaviors of the current design (which exceed the agreed-upon 
requirements in various ways) also cannot be justified with respect to 
previous agreements, and that no claim that such decisions are immutable 
can be valid.  In fact my agreement to the requirements was based on the 
fact that I found nothing in the requirements that invalidates our 
current module system.  I do not think it was unreasonable to expect 
that we would then have had a subsequent design discussion and 
agreement, let alone that requirements may be revised as new information 
becomes available, though none of that ever transpired; the issues 
process is now the only vehicle for raising design issues or problems 
with requirements that may have only become obvious after a prototype 
JDK integration has occurred, or requirements that have overreached into 
design specifics, and therefore that is the process I am using for all 
of these cases.

>> 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].

Sure, but it is pure disingenuity to imply that such a thing might 
somehow be possible in the future when it obviously will not be (without 
resolution to these issues).  It is more honest to be upfront and say 
"this module system is designed in such a way that OSGi-style bundles 
can never be mapped to it," i.e. it seems quite likely to me that we are 
consciously giving OSGi and other flexible classloader-based module 
systems an eventual death sentence if using Jigsaw-style modules will 
eventually considered (for example) a security necessity, not to mention 
the previously mentioned problems that arise if such a system is the 
basis for a Java EE application server.

-- 
- DML