> 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. > /Erik > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-October/024743.html > > <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 >>> <mailto:cthalin...@twitter.com>> wrote: >>> >>> >>>> On Oct 19, 2016, at 9:40 AM, Vladimir Kozlov <vladimir.koz...@oracle.com >>>> <mailto:vladimir.koz...@oracle.com>> wrote: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8168317 >>>> <https://bugs.openjdk.java.net/browse/JDK-8168317> >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~kvn/8168317/webrev/ >>>> <http://cr.openjdk.java.net/%7Ekvn/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 >>> <https://bugs.openjdk.java.net/browse/JDK-8168317?focusedCommentId=14013733&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14013733> >>> >>> 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 >>> >> >
