There was a bug that was just fixed yesterday such that the Java EE classes 
were not hidden.
It should have been fixed in the last nightly 114 build.

As long as the necessary Java EE API classes are on the classpath, no command 
line options are needed.

If you have the Java EE JTA API jar in the classpath, then use of 
javax.transaction.Synchronization (which is not in the JDK but is in the JTA 
API jar) will be resolved for both javac and java.

-----Original Message-----
From: Sanne Grinovero [mailto:[email protected]] 
Sent: Wednesday, April 20, 2016 8:29 AM
To: Alan Bateman
Cc: jigsaw-dev; hotspot-dev Source Developers
Subject: Re: JMH and JDK9

On Tue, Apr 5, 2016 at 3:16 PM, Andrew Dinn <[email protected]> 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

Reply via email to