On Wed, Apr 20, 2016 at 3:15 PM, Stephen Felts <[email protected]> wrote: > 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.
Thanks Stephen, indeed testing 9-ea+114-2016-04-19-162931.javare.4880.nc this is working great. [Sorry all for the forked email thread.. I should have changed the subject early on] Regards, Sanne > > -----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
