[9] RFR (xs) 8168317: [JVMCI] use reflection instead of jdk 9 Module API in Services.java

[Christian Thalinger]

> On Oct 24, 2016, at 9:01 PM, Doug Simon <doug.simon at oracle.com> wrote:
> 
>> 
>> On 24 Oct 2016, at 23:24, Christian Thalinger <cthalinger at twitter.com> wrote:
>> 
>> 
>>> On Oct 24, 2016, at 3:48 AM, Erik Joelsson <erik.joelsson at 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 <cthalinger at twitter.com> wrote:
>>>>> 
>>>>> 
>>>>>> On Oct 19, 2016, at 9:40 AM, Vladimir Kozlov <vladimir.kozlov at 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