RFR: JDK-8225213: Backport jsr166 tck tests to jdk8u
Martin Buchholz
martinrb at google.com
Wed Jun 5 01:35:32 UTC 2019
On Tue, Jun 4, 2019 at 6:07 PM Andrew John Hughes <gnu.andrew at redhat.com>
wrote:
>
> I don't think this is the best approach. JDK-8146467 looks like a pretty
> clean snapshot of the tests from not long after 8u GA. It doesn't
> include any *9Test.java files for a start. It would seem better to start
> with backporting this, rather than taking a random snapshot of the tests
> now, and hacking out all the later changes.
>
I understand the virtues of backport hygiene, having done many backports
myself, but here we're just going to disagree.
I have a changeset for you, and it is a much better test corpus for jdk8u
than the JDK-8146467 backport.
> Yes, it may be more tedious to then apply the follow-up test changesets
>
I'm not applying 36 changesets !
> than to just copy files over initially, but using the original
> changesets has the advantage that it also may include fixes to the
> source code that go with the test (e.g. JDK-8185830) If you just import
> the tests in bulk, you then have to hunt down and analyse each failure,
> eventually ending up importing the source code changes from many of
> these changesets anyway.
>
When I'm doing archaeology I look at the much more fine-grained changes in
CVS, not hg!
> We also then have the administrative benefit of being able to query the
> repository as to whether a fix is present or not, by searching for its
> bug ID.
>
When you backport an actual fix later, you will backport the change to src/
as usual and remove one of the DISABLED_JDK8_ prefixes.
(Also, the actual jdk8 fix is already in CVS!)
More information about the jdk8u-dev
mailing list