OpenLDK: Bringing the Java World into Common Lisp

OpenLDK is a Java-to-Lisp compiler and runtime written in Common Lisp. It allows Java libraries to run seamlessly within a Common Lisp environment. The process starts with reading Java bytecode, translating it into Lisp, and then using SBCL to compile the Lisp code into native machine code. Java objects coexist within the same process and heap as the Lisp application.

When a Java method is called for the first time, it triggers compilation, converting the bytecode into an intermediate representation, then into Lisp, and finally into native code through SBCL. Once compiled, the definition replaces the original stub, allowing for lazy loading of large libraries.

The translation process respects Java's semantics while providing access to Lisp. Java fields become slots, instance methods become methods of CLOS generic functions, and static methods become ordinary Lisp functions. Java's exception hierarchy aligns with a corresponding Lisp condition hierarchy. Compiled methods are stored in a persistent code cache, enabling subsequent runs to load cached code if the dependencies remain unchanged. Different images can also share compiled JDK methods.

The real power of OpenLDK emerges when developers start using these representations directly. Foreign source can be integrated within Lisp source, allowing multiple languages to coexist and interact. For instance, a Kotlin expression can be embedded within a Lisp expression, passing values and results between languages without serialization. This approach supports languages such as Scala, Groovy, Clojure, Kawa, JScheme, and ABCL. Each language retains its syntax when embedded within the Lisp code.

Clojure functions can be invoked as callable foreign-function objects within Lisp, while Lisp functions can serve as callbacks for other languages. Nested source blocks allow for complex language interplay. OpenLDK's startup time can be remarkably fast, as demonstrated by executing a Spring Boot application from a Lisp image, with subsequent launches taking approximately 84 milliseconds. This illustrates the potential for integrating Java libraries into Common Lisp applications for enhanced functionality and performance.