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

[Jan Lahoda]

Adding build-dev.

Jan

On 17.1.2019 19:53, Jan Lahoda wrote:
> On 17.1.2019 17:58, Jonathan Gibbons wrote:
>> 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.
>
> Ok. Sent as:
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012879.html
>
>
> And limited this patch to the historical data only:
> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.03/
>
> Thanks,
>     Jan
>
>>
>> -- 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
>>>>
>>>>