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

[Christian Thalinger]

> On Oct 28, 2016, at 11:23 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
>> 
>> 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?

Why can’t we have it generated?  It’s much more convenient and less maintenance overhead.  There needs to be a good reason to give this up.

> 
>>> 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