JMH and JDK9

[Alan Bateman]

On 05/04/2016 10:25, Andrew Dinn wrote:
> :
> This is actually one example of a more general problem where both Java
> EE components and Java EE applications need to employ classes which
> extend the class set of a package currently bundled in a Jigsaw module.
>
> For example, as well as the common annotations classes there is also
> package javax.transaction into which package the JDK inserts the 3 TX
> Exception (RollbackException etc) classes but omits various other TX
> classes such as Synchronization left for EE components to define -- for
> more details see this dialogue between Sanne Grinovero and Alan
>
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/007156.html
>
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/007157.html
>
> Alan's advice is for EE containers to use -upgrademodule (or -Xpatch)
> to override the classes provided in the JDK with the EE implementation
> version.
>
> This is indeed a feasible workaround (EE container implementors should
> probably be expected to understand the problem and solution). However,
> this neglects the fact that there are also standalone uses of these EE
> components
The same applies to standalone usages of these EE components (no 
different to the app server case). There is more on this topic in JEP 261.

> e.g. for unit testing or for applications which embed, say,
> TX behaviour without employing a full EE container. The test case issue
> is the most significant one here (although I am sure that EE component
> devs will be unhappy about both) since requiring the general user to
> understand and fix this problem is a different order of burden.
>
> I have asked Sanne to post a note about this to
> jpms-spec-comments at openjdk.java.net for inclusion in the list of open
> jigsaw issues to be considered by the implementors and expert group. I
> think it is important to consider whether there are other ways we can
> approach this problem. For example, would it be possible to provide an
> escape clause in Jigsaw which allows stub modules such as this to be
> tagged so that they can be automatically extended or replaced from the
> classpath without needing any intervention on the command line? n.b. I
> don't want an answer here but I want to be sure the problem is recorded
> and addressed in the proper place.
We recently updated JEP 261 proposing that "java.se" be the only java.* 
root module that is resolved when compiling code in the unnamed module 
or at runtime when the main class is loaded from the class path [1]. On 
the surface then it will "appear" to developers that the JDK does not 
have the EE components but from everything we've seen so far, then those 
EE components are usually on the class path anyway.

-Alan.

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-April/007209.html