> On Oct 24, 2016, at 9:01 PM, Doug Simon <doug.si...@oracle.com> wrote: > >> >> On 24 Oct 2016, at 23:24, Christian Thalinger <cthalin...@twitter.com> wrote: >> >> >>> On Oct 24, 2016, at 3:48 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: >>> >>> Adding build-dev, which should be included when discussing build issues. >>> For any new readers, please see [1] for the full discussion. >>> In theory it is possible to compile against and run on the exploded image >>> during the build, but I do not recommend it. Igor is correct in the build >>> team being against that design. The rationale is that it adds a lot of >>> complexity to the build. The exploded image cannot be safely run until all >>> java modules have been compiled as it introduces races. Maintaining the >>> build with such a construct will be very brittle when other changes are >>> made. We did allow the gensrc for jdk.vm.ci to run in this way for a short >>> time, since it was only supported on Linux x64, where these races are >>> rarer, but if this would ever need to be built on Windows, we would be in >>> trouble quickly. Luckily, jdk.vm.ci was able to refactor away from needing >>> this annotation processing for that module. >>> I certainly prefer the reflection solution proposed here, but find it sad >>> that it's needed. >>> >> >> The problem I have with this solution is that jdk.vm.ci code is now >> restricted to JDK N-1 code. This might be ok right now because we are able >> to work around that issue with reflection but when important features like >> Valhalla come around this is a problem. >> >> Value types will be hugely important for JVMCI and its compilers and we >> simply cannot just skip one JDK release just because the build system can’t >> handle it. > > I agree. However, I suspect large parts of the JDK will also want to leverage > Valhalla so I’m guessing the build problem will have to be solved anyway at > some point.
Not necessarily. Java modules can and are using Java features of JDK N because they are compiled with a “new javac” that gets compiled before any Java modules are compiled: # The generate old bytecode javac setup uses the new compiler to compile for the # boot jdk to generate tools that need to be run with the boot jdk. # Thus we force the target bytecode to the previous JDK version. # Add -Xlint:-options to avoid the warning about not setting -bootclasspath. Since # it's running on the boot jdk, the default bootclasspath is correct. $(eval $(call SetupJavaCompiler,GENERATE_OLDBYTECODE, \ # The generate new bytecode javac setup uses the new compiler to compile for the # new jdk. This new bytecode might only be possible to run using the new jvm. $(eval $(call SetupJavaCompiler,GENERATE_JDKBYTECODE, \ So this will just work as it does already today. Annotation processors need to be handled differently because their code is actually executed. > Maybe it worth filing a tracking bug to revert these changes at that time. > > -Doug > >> >>> >>> /Erik >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-October/024743.html >>> >>> On 2016-10-19 21:54, Igor Veresov wrote: >>>> >>>>> On Oct 19, 2016, at 12:47 PM, Christian Thalinger >>>>> <cthalin...@twitter.com> wrote: >>>>> >>>>> >>>>>> On Oct 19, 2016, at 9:40 AM, Vladimir Kozlov >>>>>> <vladimir.koz...@oracle.com> wrote: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8168317 >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~kvn/8168317/webrev/ >>>>>> >>>>>> When Graal is built as part of JDK it requires first to build an >>>>>> annotation processor using boot jdk 8. >>>>>> After JDK-8167180 changes Services class is referenced by annotation >>>>>> processor but the code is using jdk 9 Module API and it can't be used >>>>>> with jdk 8. >>>>> >>>>> I left a comment in the bug: Permalink >>>>> >>>>> Basically, it should be possible to use the newly built javac to compile >>>>> the annotation processors. Erik? >>>> >>>> It’s not only about compilation it’s about running it on the bootstrap >>>> JDK, which in currently 8. >>>> >>>> igor >>>> >>>>> >>>>> Can you paste or upload the .gmk file? >>>>> >>>>>> >>>>>> Use reflection instead of Module API and use code only for running with >>>>>> jdk 9. >>>>>> >>>>>> Testing with JPRT and JDK build of Graal. >>>>>> >>>>>> Thanks, >>>>>> Vladimir
