RFR(13): JDK-8216263: Add historical data for JDK 12

[Jonathan Gibbons]

Re:

   36 #   The checkout must not have any local changes that could interfere with the new data. In particular,
   37 #   there must be absolutely no changed, new or removed files under the ${JDK_CHECKOUT}/make/data/symbols
   38 #   directory.

That seems like a simple check that could be incorporated into the 
script itself.

But, it also seems reasonable to separate enhancements like that from 
the specific issue here, to add historical data for 12.

-- Jon

On 1/17/19 8:51 AM, Jan Lahoda wrote:
> Hi Joe,
>
> On 17.1.2019 02:13, Joseph D. Darcy wrote:
>> Hi Jan,
>>
>> On 1/8/2019 2:13 AM, Jan Lahoda wrote:
>>> Hi Joe,
>>>
>>> Thanks for the comments, some responses inline. Updated webrev:
>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/
>>>
>>> On 7.1.2019 23:51, Joseph D. Darcy wrote:
>>>> Hi Jan,
>>>>
>>>> On 1/7/2019 4:48 AM, Jan Lahoda wrote:
>>>>> Hi,
>>>>>
>>>>> To make --release 12 work, we need to add historical data for JDK 12.
>>>>> The current historical data is based on:
>>>>> $ javac  -fullversion
>>>>> javac full version "12-ea+26"
>>>>>
>>>>> We may need to update the data once JDK 12 is out to cover any 
>>>>> changes
>>>>> to the APIs that might happen.
>>>>>
>>>>> The patch also adds a simple (shell) script to generate the data, so
>>>>> all that was needed to generate the data was:
>>>>> $ cd make/data/symbols
>>>>> $ sh generate-data <path-to-JDK-12>
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263
>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
>>>>>
>>>>> How does this look?
>>>>
>>>> If the overhead is small enough and we don't mind a few updates to the
>>>> JDK N+1 data, than perhaps the generation of this information could be
>>>> included as part of the start of JDK N+1 activities.
>>>
>>> That would be perfect!
>>>
>>>>
>>>> I suggest a more extensive description of how to
>>>> make/data/symbols/generate-data. For example, this builds the data for
>>>> the current release independent of whether or not the current release
>>>> has already had its data generated, correct?
>>>
>>> Yes.
>>>
>>>>
>>>> Concretely, if JDK N+1 has already forked, what is the proper way 
>>>> to get
>>>> data for JDK N? Likewise, how should a re-build of the data for JDK 
>>>> N be
>>>> done?
>>>
>>> What exactly should be there? To the existing description:
>>> # to generate (add) data for JDK N, do:
>>> # cd make/data/symbols
>>> # sh generate-data <path-to-JDK-N>
>>>
>>> I've added (in .01):
>>> # to regenerate the data for JDK N, run the above commands again
>>>
>>> What more should be there?
>>>
>>
>> I'd appreciate somewhere to have a textual discussion of how
>> make/data/symbols/symbols should be updated, the A = 10, B = 11, etc.
>> convention, what else need to be done to generate the contents of this
>> changeset.
>>
>> The <patch-to-JDK-N> is the contents of the build directory?
>>
>> In general, a description of how the data of JDK N should be added to
>> JDK (N+1).
>
> I've added more textual description to the script, an updated webrev 
> is here:
> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/
>
> Jan
>
>>
>> Thanks,
>>
>> -Joe
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190117/8e0d2961/attachment.html>