RFR: JDK-8225213: Backport jsr166 tck tests to jdk8u
Martin Buchholz
martinrb at google.com
Tue Jun 4 00:15:41 UTC 2019
---------- Forwarded message ---------
From: Martin Buchholz (JBS) <do-not-reply at openjdk.java.net>
Date: Mon, Jun 3, 2019 at 5:11 PM
Subject: [JBS] {Commented} (JDK-8225213) Backport jsr166 tck tests to jdk8u
To: <martinrb at google.com>
Martin Buchholz
<https://bugs.openjdk.java.net/secure/ViewProfile.jspa?name=martin>
*commented* on [image: 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.
[image: 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)
[image: Atlassian logo]
More information about the core-libs-dev
mailing list