RFR: JDK-8180744: Update ct.sym for JDK 10

[Jonathan Gibbons]

+1.

Re:
> There are other jdk.compiler packages already exported to jdk.jdeps. 
> And the current implementation of jdeprscan is already depending on 
> details of --release implementation in javac (that the 
> improve-platformprovider patch is trying to improve and breaks 
> jdeprscan, so this is an attempt to make it work again). 
I don't think we should change anything here, but I think we should work 
to reduce the use of javac internals in the jdk.jdeps module. I 
definitely see some low hanging fruit in javap, but at a higher level, 
getting access to different flavors of filemanager would be good.

-- Jon



On 10/19/2017 10:46 AM, Jan Lahoda wrote:
> Hi,
>
> Thanks for the comments.
>
> I've split the work into three parts:
> -the change to PlatformProvider to return a file manager:
> http://cr.openjdk.java.net/~jlahoda/8180744/webrev.02/improve-platformprovider/ 
>
> -the changes to support --release 9 (modular environment):
> http://cr.openjdk.java.net/~jlahoda/8180744/webrev.02/release-infrastructure/ 
>
> -the update to the historical data:
> http://cr.openjdk.java.net/~jlahoda/8180744/webrev.02/release-data/
>
> I was tried to limit the lengths of the lines.
>
> On 18.10.2017 23:07, Jonathan Gibbons wrote:
>> On a pragmatic level, I note that there are some excessively long lines
>> here.  I know we don't rigidly adhere to an 80 character limit, but some
>> of the lines are perversely long, and will be tedious to review in
>> followup webrevs.    A quick grep of the changeset shows 67 lines over
>> 100 characters and 36 over 120.  (This is not counting the long lines in
>> the generated files.)
>>
>> This webrev seems to include changes for another review, 8188035.
>>
>> There are distinct blobs of work here: for example, the javac work for
>> JDKPlatformProvider seems logically distinct from the changes for
>> CreateSymbols. It seems a shame the work could not have been separated
>> into distinct changesets.
>>
>> Generally, we need more documentation on the overall process for
>> creating these files, including details on the tool(s), and the various
>> file and file formats involved.
>>
>> It feels wrong to export javac internals to jdeps.  Maybe this should
>> (eventually) evolve into a more supported service API?
>
> There are other jdk.compiler packages already exported to jdk.jdeps. 
> And the current implementation of jdeprscan is already depending on 
> details of --release implementation in javac (that the 
> improve-platformprovider patch is trying to improve and breaks 
> jdeprscan, so this is an attempt to make it work again).
>
> Jan
>
>>
>> -- Jon
>>
>>
>> On 10/13/2017 05:30 AM, Jan Lahoda wrote:
>>> Hi,
>>>
>>> The patch here adds a support for --release 9 to OpenJDK. This
>>> includes adding a snapshot of the JDK 9 APIs.
>>>
>>> Notes:
>>> -several changes to the historical data in make/data/symbols:
>>> --java.management.rmi-8.sym.txt contains a few classes that were
>>> originally in java.management-8.sym.txt (this change is adjusting the
>>> structure to adhere more to the final JDK 9 module layout)
>>> --java.annotations.common-* renamed to java.xml.ws.annotation-* to
>>> adhere to the final layout
>>> --diffing of classes across releases has been improved to avoid some
>>> unnecessary class header notices in the historical data
>>> --empty files are now not written for the historical data
>>> -the (JDK)PlatformProvider.PlatformDescription(Impl) now returns a
>>> file manager, instead of a list of paths. This makes the contract
>>> cleaner, and allow to handle the ".sig" extension mostly in the file
>>> manager instead of ClassFinder. (Due to this change, JDK-8139607:
>>> '-release option forces StandardJavaFileManager' is also resolved by
>>> this patch, although it is not the primary goal of this patch.)
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180744
>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8180744/webrev.00/
>>>
>>> I'll send to build-dev as well after the javac changes will look OK.
>>>
>>> Any feedback is welcome.
>>>
>>> Thanks,
>>>     Jan
>>