Bug ID: JDK-8296269 langtools/tier1 failures with Sequenced Collections

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 20
20Resolved

The following langtools javac tests fail when run with the Sequenced Collections (JEP 431) draft implementation:

1. tools/javac/api/TestJavacTaskScanner.java

It looks like this test extracts a bunch of fine-grained information from the `List<String>` type. Since the List interface is modified by this JEP, the test fails.

2. tools/javac/processing/model/type/BoundsTest.java

This test checks proper bounds calculations for the type hierarchy. Since this JEP is modifying the collections type hierarchy -- in particular, SequencedCollection is retrofitted between Collection and List -- it affects the results of the test.

If this can be fixed soon, great. If not, I can problem-list these tests as part of the JEP 431 integration (still a couple weeks away at this writing). Or we can work out an alternative. Please advise.

For an example of the failures, see this GitHub job:

https://github.com/stuart-marks/jdk/actions/runs/3380061747/jobs/5613251565

and search for "TEST RESULT: Failed."

Fix suggested to be included into https://github.com/openjdk/jdk/pull/7387

08-11-2022

This patch to the tests addresses the problem, basically the test TestJavacTaskScanner.java "fails" because it is encountering new members (getFirst, getLast, removeFirst, removeLast ... etc) that skew the count of members the test is validating (in a fuzzy manner). The fix is to adjust the expectation (by bumping up the fudge/fuzz factor). The failure in BoundsTest.java is more straightforward and simply calls for adjusting the super type. diff --git a/test/langtools/tools/javac/api/TestJavacTaskScanner.java b/test/langtools/tools/javac/api/TestJavacTaskScanner.java index e8110396dac..8d53c3b9d6f 100644 --- a/test/langtools/tools/javac/api/TestJavacTaskScanner.java +++ b/test/langtools/tools/javac/api/TestJavacTaskScanner.java @@ -102,7 +102,7 @@ public class TestJavacTaskScanner extends ToolTester { System.out.println("#allMembers: " + numAllMembers); check(numTokens, "#Tokens", 1054); - check(numParseTypeElements, "#parseTypeElements", 158); + check(numParseTypeElements, "#parseTypeElements", 170); check(numAllMembers, "#allMembers", 52); } diff --git a/test/langtools/tools/javac/processing/model/type/BoundsTest.java b/test/langtools/tools/javac/processing/model/type/BoundsTest.java index b7e9121a956..c47b7a7de92 100644 --- a/test/langtools/tools/javac/processing/model/type/BoundsTest.java +++ b/test/langtools/tools/javac/processing/model/type/BoundsTest.java @@ -70,7 +70,7 @@ public class BoundsTest { }; private static final String[] Single_supers = { "java.lang.Object", - "java.util.Collection" + "java.util.SequencedCollection" }; private static final String NoBounds_name = "NoBoundsTest.java";

08-11-2022