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

[Maurizio Cimadamore]

On 17/10/17 18:47, Jan Lahoda wrote:
> On 17.10.2017 16:48, Maurizio Cimadamore wrote:
>> Thanks for taking care of this issue and for filing up the followup 
>> issue.
>>
>> As for this change, I guess I wished that every generated file had some
>> explanation as to how it was obtained, but as discussed offline, this is
>> not possible for the various sym.txt files - as they are all generated
>> in the same run, and to generate them sometimes you need to use files
>> that are not checked in.
>
> If desired, it would be easy to add the note (and any other note) to 
> all the files, just seemed cleaner to put it to the "main" one.
I agree with your decision.

Maurizio
>
>
> Thanks,
>     Jan
>
>>
>> So, overall, I approve this changeset as is.
>>
>> Maurizio
>>
>>
>> On 17/10/17 14:19, Jan Lahoda wrote:
>>> An updated version of the patch that records in the symbols file the
>>> arguments used to generate the -sym.txt files and that sorts the
>>> platforms in generate platforms is here:
>>> http://cr.openjdk.java.net/~jlahoda/8180744/webrev.01/
>>>
>>> Thanks for the comments so far!
>>>     Jan
>>>
>>> On 16.10.2017 13:56, Jan Lahoda wrote:
>>>> On 16.10.2017 11:52, Maurizio Cimadamore wrote:
>>>>> Hi Martin,
>>>>> I believe some comments on how files are generated are here:
>>>>>
>>>>> http://cr.openjdk.java.net/~jlahoda/8180744/webrev.00/make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java.html 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> That said, I agree it would perhaps be a nice improvement (not
>>>>> necessary
>>>>> for this particular review), to record the launcher/options used to
>>>>> generate each file as comments in the file header.
>>>>
>>>> Sure, I'll work on adding that. I'll probably add that only to the
>>>> symbols file.
>>>>
>>>>>
>>>>> Maurizio
>>>>>
>>>>>
>>>>> On 13/10/17 17:49, Martin Buchholz wrote:
>>>>>> (drive-by comments)
>>>>>>
>>>>>> It's great that generated files are marked as such, but:
>>>>>> - It's not obvious HOW these files are generated. Actually having 
>>>>>> the
>>>>>> generation command write its own invocation into the generated files
>>>>>> might be helpful.
>>>>>> - do generated files need a legal notice?
>>>>
>>>> Is it wrong to include that notice?
>>>>
>>>>>> +# ##########################################################
>>>>>> +# ### THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. ###
>>>>>> +# ##########################################################
>>>>>>
>>>>>>
>>>>>> The order of releases is surprising:
>>>>>> +generate platforms 8:7:6:9
>>>>
>>>> It is true that the order is not significant here, although it is
>>>> significant on other places - the .sym.txt files (can and currently 
>>>> do)
>>>> only store full APIs for one version (8 currently), and the rest is 
>>>> just
>>>> diffs between versions. So when reading a .sym.txt files for a 
>>>> version,
>>>> the data for the base version need to be already read.
>>>>
>>>> Thanks,
>>>>     Jan
>>>>
>>>>>>
>>>>>> On Fri, Oct 13, 2017 at 5:30 AM, Jan Lahoda <jan.lahoda at oracle.com
>>>>>> <mailto:jan.lahoda at oracle.com>> 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
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8180744>
>>>>>>     Webrev: http://cr.openjdk.java.net/~jlahoda/8180744/webrev.00/
>>>>>> <http://cr.openjdk.java.net/%7Ejlahoda/8180744/webrev.00/>
>>>>>>
>>>>>>     I'll send to build-dev as well after the javac changes will
>>>>>> look OK.
>>>>>>
>>>>>>     Any feedback is welcome.
>>>>>>
>>>>>>     Thanks,
>>>>>>         Jan
>>>>>>
>>>>>>
>>>>>
>>