Looks good to me.
-- Jon
On 2/7/19 9:21 AM, Jan Lahoda wrote:
Hello,
I've regenerated the patch using JDK 12b30, and also using the patch
from:
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012938.html
(which makes the historical record smaller).
The updated patch is here:
http://cr.openjdk.java.net/~jlahoda/8216263/webrev.04/
How does that look?
Thanks,
Jan
On 18.1.2019 18:06, Jan Lahoda wrote:
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
