You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 0298dbd
Browse filesBrowse the repository at this point in the historyBrowse files
Recognize the value modifier of Valhalla value classes (#141)
* Recognize the value modifier of Valhalla value classes
Port of google-java-format 1959806; its first attempt, 5f7a569, was
rolled back the same day. A modifier is no longer told by its text
alone: nextIsModifier checks the token against the flags of the
ModifiersTree being visited, so `value`, `sealed` and `non` stay
identifiers where they are names. Before this a lambda parameter named
`sealed` or `non` failed with "expected token: ')'". The orderer looks
VALUE and NON_* up by name with Enums.getIfPresent, since neither VALUE
nor NON_VALUE exists on JDK 21.
The value class and record tests are skipped on a JDK without
Modifier.VALUE, which is every GA release up to 27; they need a
Valhalla early-access build.
Closes#131
* Run the tests on the Valhalla early-access build
The value class tests of the previous commit are skipped on every JDK
without Modifier.VALUE, which is every release up to 27. A fourth jdk
leg runs them on the JEP 401 early-access build from jdk.java.net,
based on JDK 27 for now. No setup-java distribution serves project
builds, so the leg downloads the archive pinned by URL and checksum and
installs it as a jdkfile; both move by hand when a newer build appears.
* Expect the modifier order of the pinned Valhalla build
The first run of the Valhalla leg sorted `value final public` to
`public value final`: the JEP 401 early-access builds declare VALUE
between NON_SEALED and FINAL in javax.lang.model.element.Modifier,
whose order ModifierOrderer follows. Upstream expects `final value`,
the order of Valhalla's lworld branch, where VALUE comes last. The
tests now expect what the pinned build does; re-check them when CI
moves to a newer build.
* Run the value class tests on JDK 28 early access
JEP 401 was integrated into JDK 28 on 2026-07-31, so its early-access
builds are the JDK with value classes, and Temurin's come through
actions/setup-java as 28-ea. The leg replaces the jdk.java.net Valhalla
build pinned two commits ago: that line, based on JDK 27, declares
VALUE between NON_SEALED and FINAL in javax.lang.model.element.Modifier
and so sorted `value final public` to `public value final`. Mainline
declares VALUE last, after STRICTFP, and sorts it to `public final
value`, the order upstream's tests expect; the tests expect it again.
* Spell the early-access leg as setup-java does
The matrix entry is `28-ea`, the version actions/setup-java takes, and
the Build step strips the suffix for -PjavaRuntime, which wants the
number alone; the expression that appended `-ea` from an extra `ea`
flag goes.
* Bump gradle-wrapper from 9.8.1 to 9.8.2
Run with `./gradlew wrapper --gradle-version 9.8.2`, twice so that
9.8.2 wrote its own files: it adds the retries and retryBackOffMs
properties for the distribution download, at their defaults.
* Build the plugins' test projects with the oldest Gradle each JDK runs
The Gradle plugins' tests built their projects with Gradle 9.3.1, the
oldest the plugins support, on the JVM of the test, so the JDK 27 leg
left them out: 9.3.1 does not run on Java 27 (Gradle's compatibility
table names 9.8.0 as the first that does), and every TestKit build
failed with "Unsupported class file major version 71". The reason in
ci.yml blamed the wrapper's Gradle, which never mattered.
GradleTestProject now reads the version from testkit.gradleVersion,
which the build sets from -PtestkitGradleVersion, and CI's jdk legs
name the oldest Gradle that runs on their JDK: 9.3.1 on 25, 9.4.0 on
26, 9.8.0 on 27. Only 28-ea keeps the exclusion, since no Gradle
release runs on Java 28 yet.
* Try the plugins' tests on 28-ea with Gradle 9.8.2
Gradle 9.8.2 claims Java 27, not 28, so the leg finds out whether its
TestKit builds run on 28-ea regardless. If they do not, the leg goes
back to leaving them out.
* Leave the plugins' tests out on 28-ea again
The try with Gradle 9.8.2 failed as its release notes suggested: it
compiles no build script on Java 28, "Unsupported class file major
version 72". The leg excludes the Gradle plugins' tests again, with
that as the reason, until a Gradle release runs on Java 28.
0 commit comments