It is complete, and I’ve found it extremely usable when writing code to trawl over a large number of class files. Looks like it should be good for code generation as well but I haven’t used that yet.
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)
> The better question is why use Java for anything these days.
Java (the language) is pretty much "C for the JVM." By that, I mean frameworks/libraries intended for maximum potential use in languages running on the JVM (such as Kotlin, Scala, and of course Java) all support Java (the language) interoperability. Many written in alternate languages targeting the JVM, such as Akka[0], typically have some degree of Java (the language) support as well.
While I prefer to program in one of the alternate programming languages targeting the JVM, I understand why many OSS projects are implemented in Java (the language) for the reasons outlined above.
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.
"fatter, compiler is slower, code completion is slow as hell" - if that's all you want out of your programming language, then Java is probably a good choice for you.
For others that value the things that Kotlin brings over Java (even modern Java), and for the ways in which it delivers a simpler experience than Scala - I think it's a pragmatic and sensible decision.
https://openjdk.org/jeps/484
bytebuddy predates it by at least a decade.
This came to be, because Oracle noticed everyone, including themselves, were depending on ASM, so the JEP was born.
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.
https://asm.ow2.io/
https://github.com/square/javapoet
I've used it to do a mass refactoring of an annotation-based library. Worked pretty great.
Java (the language) is pretty much "C for the JVM." By that, I mean frameworks/libraries intended for maximum potential use in languages running on the JVM (such as Kotlin, Scala, and of course Java) all support Java (the language) interoperability. Many written in alternate languages targeting the JVM, such as Akka[0], typically have some degree of Java (the language) support as well.
While I prefer to program in one of the alternate programming languages targeting the JVM, I understand why many OSS projects are implemented in Java (the language) for the reasons outlined above.
0 - https://github.com/akka/akka
For others that value the things that Kotlin brings over Java (even modern Java), and for the ways in which it delivers a simpler experience than Scala - I think it's a pragmatic and sensible decision.