--- title: OpenLDK: Bringing the Java World into Common Lisp description: OpenLDK is a JIT compiler and runtime for Java written in Common Lisp, translating JVM bytecode into Lisp that SBCL compiles to native code. It also runs... canonical: https://daily.dev/posts/openldk-bringing-the-java-world-into-common-lisp-txfjlwkxi twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: OpenLDK: Bringing the Java World into Common Lisp | daily.dev og:description: OpenLDK is a JIT compiler and runtime for Java written in Common Lisp, translating JVM bytecode into Lisp that SBCL compiles to native code. It also runs... og:url: https://daily.dev/posts/openldk-bringing-the-java-world-into-common-lisp-txfjlwkxi og:image: https://api.daily.dev/og/posts/TXfjLwKxI.png og:image:alt: OpenLDK: Bringing the Java World into Common Lisp og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # OpenLDK: Bringing the Java World into Common Lisp **[Hacker News](https://daily.dev/sources/hn)** · 13 min read · 2 upvotes · 0 comments ## Summary OpenLDK is a JIT compiler and runtime for Java written in Common Lisp, translating JVM bytecode into Lisp that SBCL compiles to native code. It also runs Kotlin, Scala, Groovy, Clojure, Kawa, JScheme, and ABCL, letting one Lisp expression pass a value through all seven languages. A saved, pre-initialized Spring Boot application launches in about 84 milliseconds, versus 1261.7 ms for a plain warm image and 2138.3 ms for a HotSpot fat jar. GraalVM native image is still faster and smaller at 53.5 ms and 41 MB, but OpenLDK keeps its class loader and JIT so new classes can compile after launch. The project still lacks bytecode verification and targets SBCL on Linux. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How fast does a saved OpenLDK Spring Boot snapshot image start compared to GraalVM native image? An OpenLDK snapshot image starts in a median of 83.9 ms with 175 MB peak RSS, while a GraalVM native image of the same Spring Boot command-line app starts in 53.5 ms using 41 MB. Both beat plain HotSpot startup, which ranges from about 595 ms with Spring AOT plus JDK AOT cache up to 2138 ms for a fat jar. _Comparing JVM startup strategies for Spring Boot is easier when the benchmarks are gathered in one place on daily.dev._ ### What is OpenLDK and how does it run Java code inside Common Lisp? OpenLDK is a JIT compiler and runtime for Java written in Common Lisp that reads Java bytecode, translates it into Lisp, and lets SBCL compile that Lisp into native machine code, with Java objects living in the same process and heap as the Lisp application. It targets JDK 25 and uses OpenJDK's runtime libraries from JMOD files. _Developers tracking unusual JVM runtime approaches can follow projects like this on daily.dev._ ### How does OpenLDK's Spring Boot startup approach differ from CRaC (Coordinated Restore at Checkpoint)? OpenLDK does not implement the CRaC API or preserve running threads; instead it uses SBCL's image-saving machinery to call main again with the Spring context already present, while CRaC restores a checkpointed JVM process. This means thread pools and other process-local resources need extra attention when designing an application around OpenLDK's snapshot approach. _Weighing checkpoint-restore options for faster Java startup is simpler with comparisons like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 3 discussions and 13 comments across hackernews, lobsters (as of 2026-10-28). **TL;DR:** Reaction is enthusiastic and mostly niche/technical, with people praising the ambition of bridging the JVM and Lisp worlds and musing about Lisp's future relevance, though a few raise practical caveats about interop cost and off-topic UI nitpicks. **Sentiment:** 55% positive · 35% mixed · 10% skeptical **The case for** - Seen as a nice way to make the huge JVM ecosystem (Java, Kotlin, Clojure) available inside Common Lisp. - Some find it exciting as a possible full-circle moment for Lisp given renewed interest from AI/LLM workflows. - One person notes it already appears to work with another project (Jolt) as a proof of concept. **The pushback** - Using it requires paying an interop cost, making it less suitable when Java library speed is a hard constraint. - Tangential debate over whether LLMs can reliably balance parens casts some doubt on the AI-language tangent. - A UI bug (non-functional light mode button) was flagged, unrelated to the core project. **By community** - lobsters (positive): Single commenter praises the project and suggests extending the same approach to other languages like Racket or Erlang. - hackernews (mixed): Discussion mixes genuine enthusiasm for the Lisp/JVM bridge with tangential debate about Lisp as an AI language and minor site nitpicks. **Hottest debate:** Whether Lisp could become a natural 'lingua franca' for LLM-generated code, versus skepticism that LLMs can even reliably balance parentheses. **Open questions** - Could the same bytecode-to-Lisp translation approach be extended to other language runtimes like Racket or Erlang? - Would LLMs benefit from or even prefer generating Lisp-like structured code over conventional syntax? **Highlights** > I think OpenLDK allow you to use the Java world for sbcl when you don't want to use Clojure or ABCL. But using OpenLDK requires you to pay the interop cost and when speed of the java libraries is not a sharp constrain. > — [Trusteando on hackernews](https://news.ycombinator.com/item?id=50262378) > thank you for posting, I do not have much to add, but this is pretty nice -- a huge JVM ecosystem (Java, Kotlin, Clojure) , made availabe into common Lisp (with lazy linking/loading-like method of translating jvm int clos). I am thinking having the same approach for Racket, Erlang would also be great to make the JVM ecosystem available to those. > — [vladislavp on lobsters · 2 points](https://lobste.rs/s/cf8mdy/openldk_bringing_java_world_into_common#c_1wxqr7) > Wouldn’t it be wonderful if, in the world of LLMs, Lisp became the new lingua franca, because we don’t have to convince humans that parens are scary, and because it enables exactly this kind of magic. Full circle for Lisp as an AI language. > — [mgdev on hackernews · 2 comments](https://news.ycombinator.com/item?id=50263832) > LLMs can’t count. Do you think they can balance parens? Personally, I’ve wondered why they don’t just generate machine code. > — [jonhohle on hackernews · 2 comments](https://news.ycombinator.com/item?id=50266804) > Incidentally, it looks like this idea also works with Jolt now. It's still in alpha stages, but works as a proof of concept. https://github.com/jlt-commons/jolt-openldk > — [yogthos on hackernews](https://news.ycombinator.com/item?id=50266056) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50256827) · 2 points · 0 comments - [lobsters](https://lobste.rs/s/cf8mdy/openldk_bringing_java_world_into_common) · 18 points · 1 comments - [hackernews](https://news.ycombinator.com/item?id=50232101) · 81 points · 12 comments ## Similar posts on daily.dev - [Speed up Java Startup with Spring Boot and Project Leyden](https://daily.dev/posts/speed-up-java-startup-with-spring-boot-and-project-leyden-14bdnocfp) · Piotr Minkowski TechBlog · 13 upvotes · 1 comments - [GraalVM: Fast Java, Fine Print](https://daily.dev/posts/graalvm-fast-java-fine-print-fgozwvxtr) · Medium · 11 upvotes · 0 comments - [A Road to Lisp: Which Lisp](https://daily.dev/posts/a-road-to-lisp-which-lisp-5slqf0fdz) · Hacker News · 1 upvotes · 0 comments - [Supercharge your JVM Performance with Project Leyden and Spring Boot – Inside.java](https://daily.dev/posts/supercharge-your-jvm-performance-with-project-leyden-and-spring-boot-inside-java-gkoh8jpxx) · Inside Java · 0 upvotes · 0 comments --- Tags: [#java](https://daily.dev/tags/java), [#spring-boot](https://daily.dev/tags/spring-boot), [#jvm](https://daily.dev/tags/jvm) [View this post on daily.dev](https://daily.dev/posts/openldk-bringing-the-java-world-into-common-lisp-txfjlwkxi) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"OpenLDK: Bringing the Java World into Common Lisp","url":"https://daily.dev/posts/openldk-bringing-the-java-world-into-common-lisp-txfjlwkxi","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/openldk-bringing-the-java-world-into-common-lisp-txfjlwkxi"},"datePublished":"2026-10-27T18:02:41.699Z","dateModified":"2026-10-28T06:19:44.310Z","description":"OpenLDK is a JIT compiler and runtime for Java written in Common Lisp, translating JVM bytecode into Lisp that SBCL compiles to native code. It also runs...","image":"https://media.daily.dev/image/upload/s--ZrL_HSsR--/f_auto/v1722860399/public/Placeholder%2006","thumbnailUrl":"https://media.daily.dev/image/upload/s--ZrL_HSsR--/f_auto/v1722860399/public/Placeholder%2006","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/openldk-bringing-the-java-world-into-common-lisp-txfjlwkxi","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"java,spring-boot,jvm","timeRequired":"PT13M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"OpenLDK: Bringing the Java World into Common Lisp"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/openldk-bringing-the-java-world-into-common-lisp-txfjlwkxi#faq","mainEntity":[{"@type":"Question","name":"How fast does a saved OpenLDK Spring Boot snapshot image start compared to GraalVM native image?","acceptedAnswer":{"@type":"Answer","text":"An OpenLDK snapshot image starts in a median of 83.9 ms with 175 MB peak RSS, while a GraalVM native image of the same Spring Boot command-line app starts in 53.5 ms using 41 MB. Both beat plain HotSpot startup, which ranges from about 595 ms with Spring AOT plus JDK AOT cache up to 2138 ms for a fat jar. Comparing JVM startup strategies for Spring Boot is easier when the benchmarks are gathered in one place on daily.dev."}},{"@type":"Question","name":"What is OpenLDK and how does it run Java code inside Common Lisp?","acceptedAnswer":{"@type":"Answer","text":"OpenLDK is a JIT compiler and runtime for Java written in Common Lisp that reads Java bytecode, translates it into Lisp, and lets SBCL compile that Lisp into native machine code, with Java objects living in the same process and heap as the Lisp application. It targets JDK 25 and uses OpenJDK's runtime libraries from JMOD files. Developers tracking unusual JVM runtime approaches can follow projects like this on daily.dev."}},{"@type":"Question","name":"How does OpenLDK's Spring Boot startup approach differ from CRaC (Coordinated Restore at Checkpoint)?","acceptedAnswer":{"@type":"Answer","text":"OpenLDK does not implement the CRaC API or preserve running threads; instead it uses SBCL's image-saving machinery to call main again with the Spring context already present, while CRaC restores a checkpointed JVM process. This means thread pools and other process-local resources need extra attention when designing an application around OpenLDK's snapshot approach. Weighing checkpoint-restore options for faster Java startup is simpler with comparisons like this on daily.dev."}}]} ```