21.0.2

[abashev]

The output is the same as 21.0.1's, so this release needs no reformatting run. It brings a playground that formats Java in the browser, a Gradle plugin that carries the formatter inside it, and the native binary in IntelliJ IDEA for any project.

Playground

• The formatter is compiled to WebAssembly, and the release carries it as open-java-format-wasm-21.0.2.zip, signed and listed in checksums_sha256.txt like every other file. It runs the playground, which formats Java in the browser and sends nothing anywhere. On all 915 test cases its output matches the runnable jar's byte for byte (#21, #196).

Gradle plugin

• The formatter comes inside the plugin. A build declares nothing for it and needs no repository for it, and the root project of a multi-project build needs neither a repository nor java. The jars are extracted on first use into ~/.gradle/open-java-format-caches/, and the plugin jar grows from 64 KB to 6.3 MB (#20, #198).
• Another formatter version is declared in palantirJavaFormat in the root project, as before. It and the native binary now resolve through the repositories of each project that formats: a build that declares repositories only in the root project has to declare them where it formats too (#198).
• formatDiff and the Spotless step work with Gradle's configuration cache. Up to 21.0.1 they failed with it on (#193, #195).
• spotlessJava is taken from the build cache only for the same sources, formatter and Spotless settings, and only when it formatted. The cache key holds across directories and machines (#198).
• Parallel builds work: a subproject no longer resolves the root project's configurations, which Gradle refused with "attempted without an exclusive lock" (#198).
• Without the --add-exports flags, spotlessJava fails and names them. It used to record a lint of every file, NoClassDefFoundError: Could not initialize class com.palantir.javaformat.java.ImportOrderer, which the build cache kept handing back after the flags were added (#198).
• openjavaformat.native.formatter decides only how the build runs the formatter. It no longer switches on the native binary in IntelliJ IDEA: tick Use native binary there once (#197).
• NativePalantirJavaFormatStep, which could never run, is gone (#194, #198).

IntelliJ IDEA plugin

• The native binary runs in any project, with Gradle, Maven or neither: tick Use native binary in the plugin's settings, now under Tools, and click Download, or choose a binary of your own. Before, only the Gradle plugin could switch it on. On 162 files on Apple silicon, Reformat Code takes 6.0 s with it and 88.6 s with the Java-based formatter (#197).
• The binary comes from Maven Central, is checked against its SHA-256 and is kept once for the whole IDE. After an update of the plugin, a notification offers the newer binary (#197).
• The settings page shows the Active formatter and no longer has the Code style list, which never reached the formatter. idea.log says which formatter runs (#197).
• The plugin's errors go to its page on the JetBrains Marketplace. A release IDE sends them when the user lets it send error reports automatically; an EAP build shows them with Report. The formatter failing to run is now reported, a syntax error in the file being formatted is not (#199).

Library

• Style.PALANTIR is back as a deprecated alias of Style.OJF and formats the same, so code that names it, or looks it up with Style.valueOf("PALANTIR"), keeps working after the change of coordinates (#200).
• The formatter depends on org.jspecify:jspecify instead of com.google.code.findbugs:jsr305 (#201).

Thanks

To Guillaume Laforge, for bringing back Style.PALANTIR, and to cobr123, whose open-java-format-wasm-demo showed that the formatter compiles to WebAssembly and was offered for the site.

---

This discussion was created from the release 21.0.2.