RFR: JDK-8225213: Backport jsr166 tck tests to jdk8u

[Martin Buchholz]

On Tue, Jun 11, 2019 at 7:38 PM Andrew John Hughes <gnu.andrew at redhat.com>
wrote:

>
>
> On 05/06/2019 02:35, Martin Buchholz wrote:
> >
> >
> > On Tue, Jun 4, 2019 at 6:07 PM Andrew John Hughes <gnu.andrew at redhat.com
> > <mailto: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!)
>
> Are you planning to also submit the subsequent changes required here?
>
> My reticence here is over long-term maintainability. If you're planning
> to maintain these tests in 8u, then I have no real problem with you
> doing it in the way that seems best to you, even if it seems odd from my
> perspective.
>

I have been maintaining this test suite for many years.
But I don't plan to do much more work on jdk8u specifically.
Nor do I foresee others likely to do non-trivial work on it.
If a bug fix is backported from current jdk head, just the removal of a
"DISABLED_JDK8_" is needed.
Yes, in a sense my backport will be a fork that will "bitrot", but for
jdk8u that's perfectly fine.  Really!



> However, if you just plan to submit this patch and leave the rest for
> someone else to sort out, it's a different story.
>

If you find flaky failures, I will fix.
(most likely a missing "DISABLED_JDK8_")