Updated conformance text for Java SE 9

[Volker Simonis]

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:
>> the overall wording sounds good to me. However I wonder if the
>> "upgradeable" attribute of a module shouldn't be made more explicit?
>>
>> The current specifications seems to be very vague, in the sense that
>> it uses expressions like "by example"
>>
>>     "A Java SE module is upgradeable if, and only if, it defines an API
>>     that is subject to replacement.  Only a small number of Java SE
>>     modules fall into this category.  Examples are.."
>>
>> or "most":
>>
>>     "A Java SE module is non-upgradeable if it is essential to the
>>     integrity of the Platform.  Most Java SE modules fall into this
>>     category.."
>>      => what's the definition of ESSENTIAL here?
>>
>> or "typically, generally":
>>     "Java SE modules typically indicate in their specifications whether
>>     they are upgradeable.  Non-Java SE modules generally need no
>>     such indication..."
>>
>> So I wonder if there's a fixed (i.e. mandated by the standard) set of
>> modules which HAVE TO BE upgradable and which AREN'T ALLOWED to be
>> upgradable?
>
> Yes, there is a fixed list.  The next draft of the 379 specification
> will include that list, and it will identify exactly which modules are
> upgradeable.
>
> FYI, they are:
>
>   java.activation
>   java.compiler
>   java.corba
>   java.transaction
>   java.xml.bind
>   java.xml.ws
>   java.xml.ws.annotation
>

OK, thats good.

>>             I also don't know if this has been discussed before, but
>> wouldn't it be better to make the "upgradeable" attribute explicit by
>> either encoding it into the module info of a module or by introducing
>> a new annotation on the module (equivalent to "@Deprecated"
>> annotation)?
>
> We've considered that, but it doesn't seem worth the added complexity
> given that all but one of these modules is deprecated for removal.
>
>> Finally, what are the rules for upgradeable modules with respect to
>> requires/requires transitive? Does an upgradeable module need to have
>> the exactly same dependencies like the module it replaces?
>
> No.
>
>> And what about the "exports" of an upgradeable module? Can it extend
>> the exports of the module it replaces? And if not, should this be
>> checked by the implementation?
>
> An upgraded version of an upgradeable module can, in principle, be
> arbitrarily incompatible with the original module.  Whether anyone
> would actually use it is a different question.
>
>> You mention that "an Implementation is not required to check" if an
>> upgradeable module really "exports APIs that are newer than those
>> exported by the version in the Implementation". But can an upgradeable
>> module really export a changed or completely different API
>
> Yes.
>
>>                                                            and isn't
>> the Implementation required to check that?
>
> No.
>
>>                                            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.

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?

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?

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

Regards,
Volker

>
> - Mark