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
