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

[Jan Lahoda]

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.

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