On 05/06/2019 01:15, Martin Buchholz wrote: > (Trying to correct my mistake of not having cc'ed jdk8u-dev) > > On Mon, Jun 3, 2019 at 5:15 PM Martin Buchholz <marti...@google.com > <mailto:marti...@google.com>> wrote: > > > > ---------- Forwarded message --------- > From: *Martin Buchholz (JBS)* <do-not-re...@openjdk.java.net > <mailto:do-not-re...@openjdk.java.net>> > Date: Mon, Jun 3, 2019 at 5:11 PM > Subject: [JBS] {Commented} (JDK-8225213) Backport jsr166 tck tests > to jdk8u > To: <marti...@google.com <mailto:marti...@google.com>> > > > __ > Martin Buchholz > <https://bugs.openjdk.java.net/secure/ViewProfile.jspa?name=martin> > *commented* on Enhancement JDK-8225213 > <https://bugs.openjdk.java.net/browse/JDK-8225213> > > > Re: Backport jsr166 tck tests to jdk8u > <https://bugs.openjdk.java.net/browse/JDK-8225213> > > https://cr.openjdk.java.net/~martin/webrevs/jdk8/jsr166-tck/ > > Backport Strategy: > Copy the tck directory from jdk head into the corresponding place in > jdk8u, then delete all jdk9 API files (*9Test.java and > SubmissionPublisherTest.java), then fix all "unknown symbol" compile > errors by commenting out the test that uses it, then disable all > failing tests by prepending the test name with "DISABLE_JDK_". > > Follow-on changes can re-enable some of the tests by backporting > fixes and removing "DISABLE_JDK_" from relevant tests. There are > files in jsr166 CVS in src/jdk8 that pass these tests and run on jdk8 > BUT: > - these fixes were not considered important and/or safe enough at > the time to be worth backporting > - the files in src/jdk8 implement a superset of the jdk8u API (they > include enhancements) that would need to be removed. > - jsr166 code is subtle, concurrency bugs tend to be latent, and so > backports are risky, and jdk8u is supposed to be very stable. That > said, there are known concurrency buglets in jdk8u. With hindsight, > it would have been good to fix them around the jdk10 release time. > > Add Comment > <https://bugs.openjdk.java.net/browse/JDK-8225213#add-comment> Add > Comment <https://bugs.openjdk.java.net/browse/JDK-8225213#add-comment> > > > > This message was sent by Atlassian Jira (v7.13.3#713003-sha1:0709f78) > Atlassian logo >
Thanks for forwarding. 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. Yes, it may be more tedious to then apply the follow-up test 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. 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. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew
