Motivation
- Enable correct NullAway analysis
- Pick up toolchain fixes and improvements
Toolchains
- Require JDK 25 for JVM toolchain (keep Java 17 runtime compatibility)
- Require Kotlin 2.3.20 for Kotlin toolchain (keep Kotlin 2.2 runtime
compatibility)
- Require JDK 25 for Gradle daemon JVM (via
gradle-daemon-jvm.properties)
- Fix javac and kotlinc warnings from toolchain upgrades
CI
- Bump GitHub workflows to JDK 25
Building Kotlin
- Bump Kotlin language level to 2.2 to match stdlib version
- Consolidate build logic into pklKotlinBase.gradle.kts
- Adopt modern Kotlin plugin syntax
- Fix new kotlinc warnings
- Update ktfmt to 0.62
- first version compatible with Kotlin 2.3.20
- changes formatting compared to 0.61
- Replace dependency resolution rule with BOM alignment
- rule was too broad and interfered with toolchain/runtime separation
Testing
- Expand matrix to JDK 25 (LTS) and 26
- Ensure each matrix task can be run independently
- Fix KotlinCodeGeneratorsTest and EmbeddedExecutorsTest on affected
JDKs
- Disable one test in CliCommandTest on affected JDKs (failure cause
unknown)
Compatibility fixes
- Fix reflective access in DocGenerator on affected JDKs
Build fixes
- Fix misuse of `task.enabled` vs. `report.required`
- Fix `gradlew tasks` on Windows
- Downgrade Spotless to 8.3.0 to (hopefully) work around sporadic
NoClassDefFoundError
Result
- NullAway runs correctly
- Broader JDK test coverage
- More reproducible and potentially faster builds
* Update dependencies
1. Remove */gradle.lockfile files
2. Run `gradle updateDependencyLocks` and commit
* Update multi-JDK testing to use simple Test task, add junit-platform-launcher to dependencies
- Don't use JvmTestSuite (we don't use another test runner, we use the same classpath)
* Add junit-platform-launcher to libs (prevent an issue where junit-engine and junit-launcher can fall out of sync)
This changes the Gradle build to always create multi-jdk tasks,
and instead use the `enabled` property to determine whether the task
is actually ran or not.
The has the following benefits:
* IntelliJ and other tools understand the task execution graph (e.g. testJdk20 shows up as a task)
* JDK-specific Gradle configurations always exist, so `updateDependencyLocks` is consistent.
This adds logic to build and publish the other executables related to Pkl.
These are:
* pkl-doc
* pkl-codegen-kotlin
* pkl-codegen-java
pkl-codegen-kotlin and pkl-codegen-java are published as executable JARs, whereas pkldoc is published both as an executable JAR, and also native executables (matching the set of os/arch supported by Pkl).
The reason this only publishes executable JARs for pkl-codegen-kotlin and pkl-codegen-java is because we expect that the Java requirement is not a problem for these users, and that the native executable provides negligible added value.
As part of this, the following changes are made:
* Introduce `pklJavaExecutable` plugin, which sets up building and publishing of executable JAR.
* Introduce `pklNativeExecutable` plugin, which sets up building and publishing of native executables.
* Introduce `NativeImageBuild` Gradle task, which knows how to build native-image executables.
* Introduce `ExecutableSpec` extension, for projects that publish executables to configure how those executables should be published.
* `./griddles buildNative`, by default, will only build the executable of the host OS/Arch, and will no longer cross-build.
* The target arch of `./gradlew buildNative` can be changed using `-Dpkl.targetArch=<aarch64|amd64>`.
* On linux/amd64 only, with `./gradlew buildNative`, a statically linked executable can be built using `-Dpkl.musl=true`
* Make `javaExecutable` a dependency of `assemble`
* Make `testStartJavaExecutable` a dependency of `check`
* Change name `pklNativeBuild` to `pklNativeLifecycle` to better match the plugin's purpose
* Remove Truffle SVM classes from main source set (don't publish these classes as part of the pkl-cli JAR)
* Change CircleCI definition to publish new executables
* Change CircleCI definition to call `buildNative` instead of individual task names
This updates the GraalVM and Truffle libraries to 2024.1.2.
This also updates the build logic to compile Java sources using Java 21, due to some compile-only dependencies within GraalVM/Truffle using class file version 65. However, the produced artifact is still compatible with Java 17.
This also changes the Gradle build logic to use toolchains, and to test the Java libraries with JDK 17 and 21.
One consequence of this change is that Truffle is no longer shaded within the fat jars.
feat: support for jvm21+ toolchain
feat: support for gradle toolchains
feat: pass -PnativeArch=native to build with -march=native
test: multi-jdk testing support
test: support for jvm-test-suite plugin
test: add tasks to run jpkl eval on multiple jdks
test: make jdk exec tests respect multi-jdk flags and ranges
fix: remove mrjar classes at >jvm17 from fatjars
fix: use jdk21 to run the tests (needed for Unsafe.ensureInitialized)
fix: truffle svm dependency is required after graalvm 24.0.0
fix: warnings for gvm flag usage, renamed truffle svm macro
fix: build with --add-modules=jdk.unsupported where needed
fix: don't use gu tool for modern graalvm versions
fix: catch Throwable instead of deprecated-for-removal ThreadDeath
chore: buildinfo changes for JVM targets, toolchains
chore: enforce testing at exactly jdk21
chore: enforce build tooling at jdk21+
chore: bump graalvm/truffle libs → 24.1.2
chore: toolchains for buildSrc
Signed-off-by: Sam Gammon <sam@elide.dev>
Changes:
- Update wrapper by running the following command:
./gradlew wrapper --gradle-version 8.11 --gradle-distribution-sha256-sum
57dafb5c2622c6cc08b993c85b7c06956a2f53536432a30ead46166dbca0f1e9
- Verify wrapper JAR integrity according to:
https://docs.gradle.org/current/userguide/gradle_wrapper.html#
manually_verifying_the_gradle_wrapper_jar
- Replace usages of deprecated method `Project.exec` with `ExecOperations.exec`
- Convert extension function `Task.configureInstallGraalVm` to task class `InstallGraalVm`
- a task class is the cleanest way to get hold of `ExecOperations`
- Move extension property `BuildInfo.GraalVm.downloadFile` into class `GraalVm`
- Don't apply plugin `pklGraalVm` in project `bench` (unnecessary, now causes error)
This adds support for Windows.
The in-language path separator is still `/`, to ensure Pkl programs are cross-platform.
Log lines are written using CRLF endings on Windows.
Modules that are combined with `--module-output-separator` uses LF endings to ensure
consistent rendering across platforms.
`jpkl` does not work on Windows as a direct executable.
However, it can work with `java -jar jpkl`.
Additional details:
* Adjust git settings for Windows
* Add native executable for pkl cli
* Add jdk17 windows Gradle check in CI
* Adjust CI test reports to be staged within Gradle rather than by shell script.
* Fix: encode more characters that are not safe Windows paths
* Skip running tests involving symbolic links on Windows (these require administrator privileges to run).
* Introduce custom implementation of `IoUtils.relativize`
* Allow Gradle to initialize ExecutableJar `Property` values
* Add Gradle flag to enable remote JVM debugging
Co-authored-by: Philip K.F. Hölzenspies <holzensp@gmail.com>
* Remove unnecessary strictfp modifier
* Add annotations to address Truffle DSL warnings (@Idempotent, @Exclusive)
* Adjust build logic to allow building cross-arch on macOS
* Add warning suppression for specialization limit (left this one as a TODO)
- Update google-java-format to a version compatible with JDK 21 and run "gw spotlessApply".
- Fix wrong test assumption
JavaCodeGenerator writes a properties file using java.util.Properties,
which doesn't guarantee order of entries.
- Fix most deprecation warnings
- Add CI job for JDK 21
This improves the development experience for (WSL) Linux users.
They can now run "./gradlew buildNative" without having a musl toolchain installed.
In this case, only the dynamically linked executable will be built.
odenix