JMH and JDK9

[Sanne Grinovero]

On Tue, Apr 5, 2016 at 3:16 PM, Andrew Dinn <adinn at redhat.com> wrote:
> On 05/04/16 11:17, Alan Bateman wrote:
>   . . .
>> 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.
>
> Ah ok, so this means that the problem has been punted to the other foot
> i.e. the only apps affected will be those which i) don't have an EE jar
> on their classpath and ii) require the (partial) stub implementations
> provided by Java SE. That sounds much better since such a configuration
> is of almost no use to anyone and hence is very unlikely to arise.

Agreed: excellent idea!

I'm eager to try it out so that we can resume testing of everything
else too; I just tried my luck with build 9-ea+114 but it didn't seem
to work: I'm going to assume this wasn't implemented yet, or should I
double check how I'm building?
Did I understand correctly that I won't need to pass any switch to
neither java nor javac, as long as I have the JavaEE jar as external
dependencies on my classpath? (i.e. if this build is "proven" on Java8
it should work on Java9 ?)

Is there an issue tracker which I could follow to watch updates on this?

Slightly unrelated, but is it expected that compilation is successful,
even though (in my specific case) javax.transaction.Synchronization
causes a java.lang.NoClassDefFoundError at runtime?

Thanks,
Sanne