Clojure 1.12.0

Clojure 1.12 produces Java 8 bytecode (same as Clojure 1.10 and 1.11), but this is expected to be the last release using a Java 8 baseline. Future releases will move the bytecode and minimum Java compatibility to a newer Java LTS release.

Clojure users want to use virtual threads on JDK 21. Prior to 1.12, Clojure lazy-seqs and delays, in order to enforce run-once behavior, ran user code under synchronized blocks, which as of JDK 21 don’t yet participate in cooperative blocking. Thus if that code did e.g. blocking I/O it would pin a real thread. JDK 21 may emit warnings for this when using -Djdk.tracePinnedThreads=full.

To avoid this pinning, in 1.12 lazy-seq and delay use locks instead of synchronized blocks.

Fix CVE-2024-22871 detailed in GHSA-vr64-r9qj-h27f:

CLJ-1327 explicitly sets the Java serialization identifier for the classes in Clojure that implement Java serialization. In Clojure 1.11.0 this changed for two classes unnecessarily and we reverted those changes in Clojure 1.11.1 - this completes that work for the rest of the classes.

Clojure data types have implemented the Java serialization interfaces since Clojure 1.0. Java serialization is designed to save graphs of Java instances into a byte stream. Every class has an identifier (the serialVersionUID) that is automatically generated based on the class name, it’s type hierarchy, and the serialized fields. At deserialization time, deserialization can only occur when the available class has an identifier that matches the class id recorded in the serialized bytes.

Clojure has never provided a guarantee of serialization consistency across Clojure versions, but we do not wish to break compatibility any more than necessary and these changes will give us more control over that in the future.

Updated dependencies:

There are many development-time cases where it would be useful to add a library interactively without restarting the JVM - speculative evaluation, adding a known dependency to your project, or adding a library to accomplish a specific task.

Clojure now provides new functions to add libraries interactively, without restarting the JVM or losing the state of your work:

These new functions are intended only for development-time interactive use at the repl - using a deps.edn is still the proper way to build and maintain production code. To this end, these functions all check that *repl* is bound to true (that flag is bound automatically by clojure.main/repl). In a clojure.main REPL, these new functions are automatically referred in the user namespace. In other repls, you may need to (require '[clojure.repl.deps :refer :all]) before use.

Library resolution and download are provided by tools.deps. However, you do not want to add tools.deps and its many dependencies to your project classpath during development, and thus we have also added a new api for invoking functions out of process via the Clojure CLI.

There are many useful tools you can use at development time, but which are not part of your project’s actual dependencies. The Clojure CLI provides explicit support for tools with their own classpath, but there was not previously a way to invoke these interactively.

Clojure now includes clojure.tools.deps.interop/invoke-tool to invoke a tool function out of process. The classpath for the tool is defined in deps.edn and you do not need to add the tool’s dependencies to your project classpath.

add-lib functionality is built using invoke-tool but you can also use it to build or invoke your own tools for interactive use. Find more about the function execution protocol on the CLI reference.

For a long time, we’ve had the clojure.java.shell namespace, but over time Java has provided new APIs for process info, process control, and I/O redirection. This release adds a new namespace clojure.java.process that takes advantage of these APIs and is easier to use. See:

Clojure programmers often want to use Java methods in higher-order functions (e.g. passing a Java method to map). Until now, programmers have had to manually wrap methods in functions. This is verbose, and might require manual hinting for overload disambiguation, or incur incidental reflection or boxing.

Programmers can now use qualified methods as ordinary functions in value contexts - the compiler will automatically generate the wrapping function. The compiler will generate a reflective call when a qualified method does not resolve due to overloading. Developers can supply :param-tags metadata on qualified methods to specify the signature of a single desired method, 'resolving' it.

Java members inherently exist in a class. For method values we need a way to explicitly specify the class of an instance method because there is no possibility for inference.

Qualified methods have value semantics when used in non-invocation positions:

Note: developers must use Classname/method and Classname/.method syntax to differentiate between static and instance methods.

Qualified method invocations with :param-tags use only the tags to resolve the method. Without param-tags they behave like the equivalent dot syntax, except the qualifying class takes precedence over hints of the target object, and over its runtime type when invoked via reflection.

Note: Static fields are values and should be referenced without parens unless they are intended as function calls, e.g (System/out) should be System/out. Future Clojure releases will treat the field’s value as something invokable and invoke it.

When used as values, qualified methods supply only the class and method name, and thus cannot resolve overloaded methods.

Developers can supply :param-tags metadata on qualified methods to specify the signature of a single desired method, 'resolving' it. The :param-tags metadata is a vector of zero or more tags: [tag …​]. A tag is any existing valid :tag metadata value. Each tag corresponds to a parameter in the desired signature (arity should match the number of tags). Parameters with non-overloaded types can use the placeholder _ in lieu of the tag. When you supply :param-tags metadata on a qualified method, the metadata must allow the compiler to resolve it to a single method at compile time.

A new metadata reader syntax ^[tag …​] attaches :param-tags metadata to member symbols, just as ^tag attaches :tag metadata to a symbol.

Clojure supports symbols naming classes both as a value (for class object) and as a type hint, but has not provided syntax for array classes other than strings.

Developers can now refer to an array class using a symbol of the form ComponentClass/#dimensions, eg String/2 refers to the class of a 2 dimensional array of Strings. Component classes can be fully-qualified classes, imported classes, or primitives. Array class syntax can be used as both type hints and values.

Examples: String/1, java.lang.String/1, long/2.

Java programs emulate functions with Java functional interfaces (marked with the @FunctionalInterface annotation), which have a single method.

Clojure developers can now invoke Java methods taking functional interfaces by passing functions with matching arity. The Clojure compiler implicitly converts Clojure functions to the required functional interface by constructing a lambda adapter. You can explicitly coerce a Clojure function to a functional interface by hinting the binding name in a let binding, e.g. to avoid repeated adapter construction in a loop, e.g. (let [^java.util.function.Predicate p even?] …​).

Calling methods that take a Supplier (a method that supplies a value) had required writing an adapter with reify. Clojure has a "value supplier" interface with semantic support already - IDeref. All IDeref impls (delay, future, atom, etc) now implement the Supplier interface directly.

Java APIs increasingly return Streams and are hard to consume because they do not implement interfaces that Clojure already supports, and hard to interop with because Clojure doesn’t directly implement Java functional interfaces.

In addition to functional interface support, Clojure now provides these functions to interoperate with streams in an idiomatic manner, all functions behave analogously to their Clojure counterparts:

All of these operations are terminal stream operations (they consume the stream).

Java collections implement streams via "spliterators", iterators that can be split for faster parallel traversal. PersistentVector now provides a custom spliterator that supports parallelism, with greatly improved performance.

Partitioning of a collection uses a series of takes (to build a partition) and drops (to skip past that partition). CLJ-2713 adds a new internal interface (IDrop) indicating that a collection can drop more efficiently than sequential traversal, and implements that for persistent collections and algorithmic collections like range and repeat. These optimizations are used in drop, nthrest, and nthnext.

Additionally, there are new functions partitionv, partitionv-all, and splitv-at that are more efficient than their existing counterparts and produce vector partitions instead of realized seq partitions.

Interning a var in a namespace (vs aliasing) must create a stable reference that is never displaced, so that all references to an interned var get the same object. There were some cases where interned vars could get displaced and those have been tightened up in 1.12.0-alpha1. If you encounter this situation, you’ll see a warning like "REJECTED: attempt to replace interned var #'some-ns/foo with #'other-ns/foo in some-ns, you must ns-unmap first".

This addresses the root cause of an issue encountered with Clojure 1.11.0, which added new functions to clojure.core (particularly abs). Compiled code from an earlier version of Clojure with var names that matched the newly added functions in clojure.core would be unbound when loaded in a 1.11.0 runtime. In addition to CLJ-2711, we rolled back a previous fix in this area (CLJ-1604).