[9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

[Mandy Chung]

> On Oct 28, 2016, at 1:52 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Thank you, Mandy
> 
> On 10/28/16 1:31 PM, Mandy Chung wrote:
>> 
>>> On Oct 26, 2016, at 5:45 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>> 
>>> http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
>> 
>> make/gensrc/Gensrc-jdk.vm.compiler.gmk
>>   This generates module-info.java.extra at build time to augment module-info.java with `uses` and `provides`.  module-info.java.extra is expected to be checked in the source.
>> 
>>   Do you expect the list of `uses` and `provides` are often changed?
> 
> Yes, Graal code changes frequently and  we need to run annotation processor to generate these dependencies for each jdk.vm.compiler (Graal) module build.
> 

When the OptionDescriptors list is changed, we can run the tool (you can add a make target if it helps) to generate the list of `uses` and `provides`.  Then update module-info.java in the source together with the changes.  That would work too, right?

>> The alternative is to declare `uses` and `provides` in module-info.java in the source repo so that a reader can see the module descriptor content without needing to do a build.  A test to detect if the module-info.java is out-of-sync with the annotated options.  In addition a make target to generate the list of `use` and `provides` can be used to generate module-info.java to be included in any change in the annotated options list.
> 
> What is "a reader”?

A person reading the code.

> And how to check "out-of-sync" without running 'processor’?

I meant a regression test that will run the annotation processor and compare with module-info.class in the image (using java.lang.module.ModuleDescriptor API)

Mandy

> Sorry, I am not familiar with all this modules build process.
> 
> Thanks,
> Vladimir
> 
>> 
>> Mandy
>>