Updated conformance text for Java SE 9

[mark.reinhold at oracle.com]

2017/7/21 7:15:44 -0700, volker.simonis at gmail.com:
> On Tue, Jul 18, 2017 at 12:33 AM, mark.reinhold at oracle.com wrote:
>> 2017/7/17 8:21:26 -0700, volker.simonis at gmail.com:
>> ...
>>> 
>>>                                           If the answer is yes, an
>>> upgradeable module could easily re-export (e.g. by wrapping) internal
>>> packages which the Implementation qualifiedly exports to the
>>> Implementation module. (I've just checked that with the current
>>> Reference Implementation it is for example possible to put a custom
>>> version of jdk.jshell onto the --upgrade-module-path which re-exports
>>> functionality from jdk.internal.misc.Unsafe).
>> 
>> You can do that if you're using an exploded JDK 9 image.  It shouldn't
>> work with a proper linked image -- if it does, that's bug.
> 
> You only can' t do it with a properly linked image because the
> reference Implementation hashes the modules to which qualified exports
> exist. But this hashing is an implementation detail of the reference
> Implementation and not a "standard" feature (which I personally
> regret). Even this hashing "safe-belt" can be easily disabled by a
> corresponding "--patch-module jdk.jshell=XXX" option where 'XXX' can
> be a non-existing directory. But that's probably something for the
> jigsaw mailing list.

FYI, the bug that enabled that hack was fixed not too long ago.

> So back to the specification. If we have a fixed list of standard
> modules which are upgradeable, I don't understand why all the other,
> non-SE modules are upgradeable by default (i.e. "A non-Java SE module
> is upgradeable unless the Implementation deems otherwise"). Why not
> define it the other way round that non-SE modules aren't upgradeable
> until the Implementation deems otherwise? Do you really think
> upgradeable non-standard modules will be useful? If yes, in which
> context?

Yes: Consider a custom linked image that contains some library and
application modules.  You might want to override some of those modules
in production, say, without having to (and maybe without being able to)
re-link the image.

I'll add some text to the specification to suggest this use case.

> And there's another problem with the upgradeable modules. Because they
> are upgradeable they obviously can't be hashed. So if somebody builds
> a custom image without an upgradeable module, a user of that image
> could easily provide his own module with the same name like the
> upgradeable module and use all of the qualified exports from the
> platform modules to the original version of the upgradeable module.
> Don't you think that this could compromise the integrity of the
> customized jlinked image?

Yes, it certainly could!  That's why we've taken care in the RI to make
sure that no interesting packages are exported to upgradeable modules.
In fact, the only packages that are exported with qualification to
upgradeable modules are from other upgradeable modules.

>>> The new spec also mentions that "a non-Java SE module is upgradeable
>>> unless the Implementation deems otherwise". As far as I can an see in
>>> the current Reference Implementation, this is not mentioned for any of
>>> the non-Java SE modules. Nevertheless most of them are not really
>>> upgradeable because of the hashing of dependent modules. So it seems
>>> that in the current Reference Implementation the fact if a module is
>>> considered "upgradable" is decided by the regexp given to the jmod
>>> command to exclude modules from being hashed (e.g.
>>> (?!java.activation|java.corba|java.se.ee|java.transaction|java.xml.bind|java.xml.ws|java.xml.ws.annotation|jdk.rmic|jdk.xml.bind|jdk.xml.ws)
>>> for java.base). Again, as previously mentioned, I think an explicit
>>> tagging would be better here.
>> 
>> I suggest that the explicit specification of upgradeability is adequate.
> 
> Yes, but as far as I understood, that will be done only for the SE
> modules and not for the other platform modules.

For clarity I'll add the following paragraph:

  The specification of an upgradeable Java SE module will indicate that
  it is upgradeable.  If the specification of a Java SE module does not
  indicate that the module is upgradeable then it is not upgradeable.

>                                                 The standard can't
> actually say anything about non-standard modules, but it could mandate
> that every module is somehow tagged as upgradeable or not.

It could, but that would require that we make upgradeability an explicit
and standard property of all modules.

Should we delay the release in order to design and implement that feature?

- Mark