Updated conformance text for Java SE 9
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Mon Jul 17 22:33:51 UTC 2017
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
> => 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
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
FYI, they are:
> 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"
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?
> 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
> and isn't
> the Implementation required to check that?
> 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.
> 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.
More information about the java-se-9-spec-observers