Yup, the ASM dependency is one that would constantly cause us headaches. A load of frameworks have a path to ASM for one reason or another and it requires an update every time you move up JVM runtimes.
It's usually not painful to update (just bump the version) but it's an annoyance.
It seems like micronaut has been able to avoid runtime bytecode generation by doing everything at compile-time. I wonder if there’s things that you can’t do the micronaut way.
Reminds me of a side project I did when first starting CS! The Java byte code specification is absolutely approachable and if you've never looked at it before I recommend it (although this project says you can still use it without that knowledge)
Kotlin is fatter, compiler is slower, code completion is slow as hell on large projects, but other than building small applications - there's really no reason to not use kotlin except for the fact that you need to actually learn the language or else you're going to end up with very very slow codebase where opening a file and waiting for syntax highlighting takes 2-3 seconds and typing autocomplete is just painfully slow.
Note that Java now has its own API for this purpose.
https://openjdk.org/jeps/484
for those who might be clicking through thinking "since when??", the emphasis is on "now" - this was released in JDK 24.
bytebuddy predates it by at least a decade.
Hence the now on my comment. :)
Ideally, tools like ByteBuddy will adopt that API as it's for low level concerns.
We are already living in an (almost) ideal world: https://github.com/raphw/byte-buddy/discussions/1798
How does that compare in terms of usability and completeness?
I have not yet used it, only raising awareness.
This came to be, because Oracle noticed everyone, including themselves, were depending on ASM, so the JEP was born.
Yup, the ASM dependency is one that would constantly cause us headaches. A load of frameworks have a path to ASM for one reason or another and it requires an update every time you move up JVM runtimes.
It's usually not painful to update (just bump the version) but it's an annoyance.
In fact, Byte buddy has a dep on ASM.
It's complete but low level compared to Byte Buddy. A better comparison is the to ASM (which is what it was meant to replace).
https://asm.ow2.io/
If you are into code generation, another project of interest is Java Poet
https://github.com/square/javapoet
I've used it to do a mass refactoring of an annotation-based library. Worked pretty great.
It seems like micronaut has been able to avoid runtime bytecode generation by doing everything at compile-time. I wonder if there’s things that you can’t do the micronaut way.
Reminds me of a side project I did when first starting CS! The Java byte code specification is absolutely approachable and if you've never looked at it before I recommend it (although this project says you can still use it without that knowledge)
The better question is why use Java for anything these days. If you really need to run something with JVM, use Kotlin.
As a Kotlin enjoyer, I find these comments counterproductive. Maybe they like the lack of extension functions?
Kotlin is fatter, compiler is slower, code completion is slow as hell on large projects, but other than building small applications - there's really no reason to not use kotlin except for the fact that you need to actually learn the language or else you're going to end up with very very slow codebase where opening a file and waiting for syntax highlighting takes 2-3 seconds and typing autocomplete is just painfully slow.