IBMSemeruTest: 4 tests fail in scheduled CI with 'LST contains missing or invalid type information' since Moderne Artifactory mirror was enabled

[timtebeek]

Symptom

Four IBMSemeruTest tests fail on every scheduled CI run since 2026-05-14:

• IBMSemeruTest.doNotUseSunNetSslInternalSslProvider
• IBMSemeruTest.hostnameVerifier
• IBMSemeruTest.doNotUseSunNetSslInternalWwwProtocolHttpsHandler
• IBMSemeruTest.fullyQualifiedPackage

All fail with:

java.lang.IllegalStateException: LST contains missing or invalid type information
Identifier->VariableDeclarations->Block->MethodDeclaration->Block->ClassDeclaration->CompilationUnit
/*~~(Identifier type is missing or malformed)~~>*/Provider
…
    at org.openrewrite.java.Assertions.assertValidTypes(Assertions.java:131)

Example runs:

• https://github.com/openrewrite/rewrite-migrate-java/actions/runs/25934344745 (2026-05-15)
• https://github.com/openrewrite/rewrite-migrate-java/actions/runs/25879328834 (2026-05-14)

Reproduction

The tests do not reproduce locally. I ran them against current main (e9113124) with:

• Single test (./gradlew test --tests "…IBMSemeruTest.doNotUseSunNetSslInternalSslProvider")
• Whole class (…IBMSemeruTest)
• Full test suite
• --refresh-dependencies
• Java 21 and Java 25

All pass locally. CI consistently fails the same 4 tests.

• Correlation with Route Maven through Moderne Artifactory cache to avoid HTTP 429 #1096

• The failures started in the first scheduled run after f56a1ead ("Route Maven through Moderne Artifactory cache to avoid HTTP 429", Route Maven through Moderne Artifactory cache to avoid HTTP 429 #1096) was merged on 2026-05-13 23:39 UTC:

• Run 25820076425 (2026-05-13 18:59, before merge, sha d5db0d75): IBMSemeruTest not failing

• Run 25832735802 (2026-05-13 23:39, merge push, sha f56a1ead): only 2m17s — actions/build@main skipped tests on push, no IBMSemeruTest output

• Run 25879328834 (2026-05-14 18:56, first scheduled run after merge, sha f56a1ead): 4 IBMSemeruTest failures ✗

• Every scheduled run since: same 4 failures

Hypothesis

These tests use JavaParser.fromJavaVersion().classpathFromResources(ctx, "sun.internal.new") to load src/test/resources/META-INF/rewrite/classpath/sun.internal.new.jar (which contains com.sun.net.ssl.internal.ssl.Provider, …Handler, etc).

In rewrite-java's JavaParser.dependenciesFromResources (rewrite-java/src/main/java/org/openrewrite/java/JavaParser.java:126), TypeTable.fromClasspath(ctx, artifactNames) is consulted first and only falls back to JAR loading for artifacts the TypeTable doesn't match. The matcher is Pattern.compile("sun.internal.new" + ".*"), so any classpath.tsv.gz resource on the runtime classpath whose POM declares an artifactId starting with sun.internal.new would intercept the lookup and skip the local JAR.

• The Moderne Artifactory cache mirror introduced by Route Maven through Moderne Artifactory cache to avoid HTTP 429 #1096 likely resolves a transitive dependency that ships a META-INF/rewrite/classpath.tsv.gz containing such an entry — locally without the mirror I have no classpath.tsv.gz resources on the test runtime classpath, which is why the JAR fallback works.

I have not proven this — it's the most consistent hypothesis given the timeline correlation and the resolution order in dependenciesFromResources.

Suggested investigation

• Adding --info to a CI run that fails would show which TypeTable resource(s) are present and what they match. Comparing the test runtime classpath before/after Route Maven through Moderne Artifactory cache to avoid HTTP 429 #1096 should confirm whether a new artifact (with a TypeTable) is being pulled through the mirror.