Clojurians Log v2

> Spring Boot 4.1.2 and Quarkus 3.40.1 apps start lol, this is hilarious

Yes, it starts and run spring boot with the benchmark toward the end

Wow. It's quite incredible

What do you get from Chez Scheme in this context, that you don’t get from the JVM? I’d like to understand the benefit and tradeoffs.

Champaca isn’t trying to beat the JVM. It exists so a Jolt program can use Java libraries without running a JVM next to it.

Without it, calling Jackson or Guava from jolt means starting a JVM beside your program and talking to it over a bridge. Champaca runs the byte code inside the Jolt process instead: Each method is compiled to native code through Chez Scheme the first time it’s called, and Java objects live in the same heap as your Jolt code. That buys you: • Plain calls: calling Java is an ordinary function call, with no serialization or IPC, and a Jolt fn works wherever Java wants a callback. • No JVM to install: bb bundle ships the JDK’s class library, minus the VM, with your program. • The real JDK: it runs the JDK’s own classes, so libraries behave as on HotSpot. Eight common libraries, Spring Boot and Quarkus give identical output. The costs: it’s a few times slower than HotSpot’s JIT. Threads take turns, under one global lock. It uses several times the memory. JNI and IPv6 aren’t supported yet. It’s a good fit for a jolt program that needs a Java library or two in-process; for heavy multi-threaded Java work, use HotSpot. It is modelled after the excellent library https://github.com/atgreen/openldk (Common Lisp)

wooooow

I feel this is kinda related to my blog post about cream. Cream sits in between babashka and a full blown JVM when it comes to startup time and memory usage but as soon as you add a few Java libraries and whatnot, you’ll soon end up losing any benefits over a full blown JVM compared to cream. So my question is: do you have a realistic scenario where jolt + your lib uses non-trivial Java libraries and it performs better (startup and/or performance / memory usage)? If not, then this is just a nice 🤯 LLM-experiment, but if there are real benefits, let me know.

Yeah, can it aot the libs easily, I wonder

I already assume AOT

Well, losing the benefits, you’re talking about the cold loading, right?

For me, the main benefit is for legacy code, if you’re building something on Jolt, but really need some existing Java library as a bridge this makes it possible. I kind of think of it like Rosetta on macOS.

it looks like you shouldn’t be using jolt + Champaca if you’re in that situation, if you look at this table: https://gist.github.com/borkdude/83a756abbd491167ea1c4ba6446dfcfb

Yeah, champaca ain’t winning any races yet lol

Prolly a 20x slow down?

@borkdude to be fair, Champaca probably has a lot of optimizing that can be done, so far it’s just proving that it’s possible to do at all

you should not compare just one number, different aspects but nothing really make sense to me here

yeah ok, I’ll take a look next year (if you’re still maintaining it, good luck ;))

I don’t see why we wouldn’t be?

Maintaining an alternative JVM seems like work, but I wish you the best haha

we’re not really maintaining an alternative JVM though, what we’re maintaining is the API layer on top of a different runtime

I’m talking about Champaca. > Java byte code becomes Chez Scheme

right, but Chez Scheme is the runtime, so it’s mechanical translation kind of like wasm

I’m building an alternative JVM right now 😬

Just a mix on TeaVM, so hopefully it’s not a maintenance nightmare

I mean, Oracle and friends bring out critical patch releases with security fixes etc. It’s not just “can we do it” right, but also “are we willing to do the boring work” that comes with maintaining a serious JVM

but if that work is mainly in lib/modules then I guess the churn would be ok-ish

but stuff like security fixes would be part of the VM runtime itself right?

Chez is maintained by Cisco for example, so it’s pretty actively developed.

and with Oracle moving into junk bonds territory, there are questions about what happens with the JVM if they go belly up > MA: Still, Oracle’s credit investors are pricing in more risk. S&P, the big credit rating agency - they downgraded Oracle’s credit in July. Now Oracle is barely above junk status. https://www.npr.org/2026/10/22/nx-s1-6007863/oracles-debt-is-growing-the-tech-giants-investors-are-concerned

The native methods seem to be implemented in , , , , , which probably is the highest point of churn

only looking at the first file https://github.com/b12n-oss/champaca/blob/main/resources/champaca/natives.ss , boy that’s a lot of code…

I mean Jolt itself has a lot of code now too 🙂

but yeah you have to map out all the elements to translate them, so a lot of it is just mechanical mapping that’s necessarily going to be long since java surface is big

but the flip side is that Java is really well specified so you can have robust regression testing

cc @bozhidar