What is the parent class loader of the class loader defining the class from JDK 8 tools.jar? Is it null?
Mandy > On Oct 8, 2015, at 2:08 PM, Keimpe Bronkhorst <keimpe.bronkho...@oracle.com> > wrote: > > Alan, > > I'm running JDeveloper with jigsaw build > 1.9.0-ea-jigsaw-nightly-h3477-20150929-b83. Compiling in-process using JSR199 > with a Javac from JDK8 tools.jar is working fine. > > Keimpe > > > On 10/8/2015 2:27 PM, Alan Bateman wrote: >> >> On 08/10/2015 20:45, Keimpe Bronkhorst wrote: >>> Alan, >>> If the user's project's JDK has a higher version than the JDK of >>> JDeveloper, the compile is done out-of-process. Otherwise an in-process >>> JSR199 is attempted. >>> Yes, -source/-target/-Xbootclasspath (and now -release) for cross-compiling >>> is another way, but it doesn't use the Javac of the user's project's JDK. >>> The user can easily set up a cross-compile in JDeveloper, but some users >>> want to use the actual Javac of their project's JDK. >> I don't want to comment on trying to mixing different versions of JDK >> modules in the same VM but I'm curious whether your loading of tools.jar in >> the target VM continues to work when you run it on jake and when targeting a >> JDK 8 or older. I would expect it should work as before, assuming of course >> that your custom class loader that is loading from the targets tools.jar >> isn't doing parent-first delegation. The latter point is important because a >> consequence of the JEP 220 work is that types that were previously in >> tools.jar are always visible when running a class path application on the >> JDK. >> >> -Alan >
