Updated conformance text for Java SE 9

[mark.reinhold at oracle.com]

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

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

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

- Mark