3 ms·

Do changes to Java itself impact e.g. Clojure? I think it uses many java primitives instead of emitting jvm byte code but I can be wrong.

lucketone 7mo ago
In general, some java language changes do involve JVM changes. So yes, it impacts other jvm languages like Closure. Here most obvious would be GC improvements.
jillesvangurp 7mo ago
Some of the standard library stuff could be usable from Clojure and other languages. The jvm level optimizations (garbage collection) should benefit all jvm languages. The language changes are mostly not that relevant unless you program directly in Java. I use Kotlin myself (after doing Java since 1995). Most of the overview here reads like they are adding a lot of stuff that Kotlin has had for many years. Structured concurrency, lazy stuff, etc. You can argue about which language does it better/nicer/etc. but that debate is a bit boring to me. But good for Java developers that they are getting some obviously useful things that so far they never had. Progress is nice. Better late than never.
- gf000 7mo ago
  Java improvements usually have a runtime component, so no, kotlin simply couldn't have had Lazy no matter what. It was just syntactic sugar for a getter.
  - jillesvangurp 7mo ago
    "Just syntactic sugar" That's what most modern programming languages provide. Syntax matters. Kotlin offers a lot of syntactic sugar for things that are a bit verbose in Java. The new structured concurrency stuff in Java is actually a great example of that. More or less does the same thing, Kotlin manages to do it with a nice Kotlin DSL. Java does it with a lot of builders and function chaining. Which is a lot less readable. In the end, Java caught up and you can now use this for more complex concurrent/parallel code (both should be possible with this, like it is with co-routines in Kotlin). Which is a good thing.
    - gf000 7mo ago
      Didn't mean to say that syntactic sugar is bad. But when Java touches a language feature they prefer doing it only when absolutely necessary and even then having the biggest part be in the runtime if possible. E.g. in the lazy case, it's backed by runtime optimizations, they are treated as proper constants. A fancy getter over a lambda is not the same thing, and that's all syntactic sugar in this case would give you.
geokon 7mo ago
Yes, kind of... for instance you can use Virtual Threads now from Clojure: https://clojure.org/news/2026/03/11/async_virtual_threads https://clojure.org/news/2026/03/11/async_virtual_threads I'm pretty sure all of Clojure runs on Java 8, so if you use some new feature I'm guessing you need to provide a fallback - but you're also going to be running on Javascript and other platforms, so that's par for the course
lmm 7mo ago
Sometimes, yes. E.g. if the value types stuff ever gets implemented, that will be very useful for other JVM languages. OTOH some changes are purely syntax sugar in Java itself (e.g. allowing multiline string literals) and those of course don't affect any other JVM language.

lucketone 7mo ago

In general, some java language changes do involve JVM changes. So yes, it impacts other jvm languages like Closure. Here most obvious would be GC improvements.

jillesvangurp 7mo ago

Some of the standard library stuff could be usable from Clojure and other languages. The jvm level optimizations (garbage collection) should benefit all jvm languages. The language changes are mostly not that relevant unless you program directly in Java. I use Kotlin myself (after doing Java since 1995). Most of the overview here reads like they are adding a lot of stuff that Kotlin has had for many years. Structured concurrency, lazy stuff, etc. You can argue about which language does it better/nicer/etc. but that debate is a bit boring to me. But good for Java developers that they are getting some obviously useful things that so far they never had. Progress is nice. Better late than never.

gf000 7mo ago
Java improvements usually have a runtime component, so no, kotlin simply couldn't have had Lazy no matter what. It was just syntactic sugar for a getter.
- jillesvangurp 7mo ago
  "Just syntactic sugar" That's what most modern programming languages provide. Syntax matters. Kotlin offers a lot of syntactic sugar for things that are a bit verbose in Java. The new structured concurrency stuff in Java is actually a great example of that. More or less does the same thing, Kotlin manages to do it with a nice Kotlin DSL. Java does it with a lot of builders and function chaining. Which is a lot less readable. In the end, Java caught up and you can now use this for more complex concurrent/parallel code (both should be possible with this, like it is with co-routines in Kotlin). Which is a good thing.
  - gf000 7mo ago
    Didn't mean to say that syntactic sugar is bad. But when Java touches a language feature they prefer doing it only when absolutely necessary and even then having the biggest part be in the runtime if possible. E.g. in the lazy case, it's backed by runtime optimizations, they are treated as proper constants. A fancy getter over a lambda is not the same thing, and that's all syntactic sugar in this case would give you.

geokon 7mo ago

Yes, kind of... for instance you can use Virtual Threads now from Clojure: https://clojure.org/news/2026/03/11/async_virtual_threads https://clojure.org/news/2026/03/11/async_virtual_threads I'm pretty sure all of Clojure runs on Java 8, so if you use some new feature I'm guessing you need to provide a fallback - but you're also going to be running on Javascript and other platforms, so that's par for the course

lmm 7mo ago

Sometimes, yes. E.g. if the value types stuff ever gets implemented, that will be very useful for other JVM languages. OTOH some changes are purely syntax sugar in Java itself (e.g. allowing multiline string literals) and those of course don't affect any other JVM language.