Live data from Hacker News

Byte Buddy is a code generation and manipulation library for Java

bytebuddy.net

31–40 of 52 posts

Re: Byte Buddy is a code generation and manipulation library for Java

#31

Earlier quoted context omitted.

> 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 problem is, if you are trying to optimize for the JVM, you are already down the wrong path. The JVM is useful in a very small niche when you want something that is faster than Python/Node , but still want cross platform support and somewhat rapid development. The cases where this applies are very niche. It may allow closer to JVM access, however the entire ecosystem is a colossal mess. The main() implementation i…

You don’t really need any of the apache commons libraries with modern java versions, if that’s what you were referring to. Also I think that most people who are considering doing jvm development would consider kotlin as an alternative language or maybe c# and dotnet as an alternative ecosystem. I believe rust, c or cpp are rarely going to be considerations for most people in that situation.

Re: Byte Buddy is a code generation and manipulation library for Java

#33

The better question is why use Java for anything these days. If you really need to run something with JVM, use Kotlin.

A recent good reason for using Java is that frontier LLMs are trained with very large amounts of high quality enterprise Java source code. Claude Code for example loves Java and its static type system. I constrain my LLM-generated Java code to only static methods of 20 LOC or less, and limit data types to those that are JSON compatible. Both of these lead to more reliable code and data that Claude Code fully understa…

Could you please expand on how you limit the generated code? I haven't dived deep into Claude code, mostly just familiar with OpenAI's offering.

Re: Byte Buddy is a code generation and manipulation library for Java

#34
post #19

Earlier quoted context omitted.

As a Kotlin enjoyer, I find these comments counterproductive. Maybe they like the lack of extension functions?

I do like the lack of extension functions. I find them confusing, especially when you can use them on things that are null.

I wonder if that confusion is due to the fact that you haven't yet wrapped your head around the fact that extension functions are "just" syntactic sugar for static functions. The implicit "this" becomes the the first parameter of the static function and function parameters can be null. Now you might ask "why not use static (/first class) functions then? Because those "feel" like less ideomatic to use then extension functions or methods that are defined on the object (hirachy) itself. But understanding why the extension type can be nullable is not the same is using it on nullable types. I restrict my extension functions to non-nullable types most of the time as well. The best exception to this preference -just to see where it makes sense- is the build-in function [toString](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/to-stri...), since you want it to return "null" if you invoke it on null.

Re: Byte Buddy is a code generation and manipulation library for Java

#35

Earlier quoted context omitted.

> 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 problem is, if you are trying to optimize for the JVM, you are already down the wrong path. The JVM is useful in a very small niche when you want something that is faster than Python/Node , but still want cross platform support and somewhat rapid development. The cases where this applies are very niche. It may allow closer to JVM access, however the entire ecosystem is a colossal mess. The main() implementation i…

I like Rust as much as the next guy, but Kotlin is the most ergonomic programming language I know. So my approach is to use Kotlin by default and should it some day become clear that the service is a bottleneck (or if the cloud cost can be lowered substancially), to only then rewrite it in Rust. At that point the service has probably already gained most of the functionality it'll ever have, which should make the Rust conversion as straight-forward as it can be.

Re: Byte Buddy is a code generation and manipulation library for Java

#36
post #21
post #8

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.

Should probably link to https://github.com/palantir/javapoet instead, as the Square version has been deprecated since 2020.

Palantir does Java? Jikes !

Re: Byte Buddy is a code generation and manipulation library for Java

#37

Earlier quoted context omitted.

The problem is, if you are trying to optimize for the JVM, you are already down the wrong path. The JVM is useful in a very small niche when you want something that is faster than Python/Node , but still want cross platform support and somewhat rapid development. The cases where this applies are very niche. It may allow closer to JVM access, however the entire ecosystem is a colossal mess. The main() implementation i…

I like Rust as much as the next guy, but Kotlin is the most ergonomic programming language I know. So my approach is to use Kotlin by default and should it some day become clear that the service is a bottleneck (or if the cloud cost can be lowered substancially), to only then rewrite it in Rust. At that point the service has probably already gained most of the functionality it'll ever have, which should make the Rust…

Have you ever coded groovy? If so, besides that it is nigh a dead pang, what does kotlin offer?

Re: Byte Buddy is a code generation and manipulation library for Java

#38

Earlier quoted context omitted.

I like Rust as much as the next guy, but Kotlin is the most ergonomic programming language I know. So my approach is to use Kotlin by default and should it some day become clear that the service is a bottleneck (or if the cloud cost can be lowered substancially), to only then rewrite it in Rust. At that point the service has probably already gained most of the functionality it'll ever have, which should make the Rust…

Have you ever coded groovy? If so, besides that it is nigh a dead pang, what does kotlin offer?

Kotlin is more type oriented, while offering a lot of niceness in terms of syntax (like not having to have a class that surrounds main).

Re: Byte Buddy is a code generation and manipulation library for Java

#39
post #26

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)

where to start?

https://docs.oracle.com/javase/specs/jvms/se8/html/

https://medium.com/@davethomas_9528/writing-hello-world-in-j...

Re: Byte Buddy is a code generation and manipulation library for Java

#40
post #19

Earlier quoted context omitted.

I do like the lack of extension functions. I find them confusing, especially when you can use them on things that are null.

I wonder if that confusion is due to the fact that you haven't yet wrapped your head around the fact that extension functions are "just" syntactic sugar for static functions. The implicit "this" becomes the the first parameter of the static function and function parameters can be null. Now you might ask "why not use static (/first class) functions then? Because those "feel" like less ideomatic to use then extension f…

I have wrapped my head around it. I think it's confusing to the reader and creates awkward semantics.
Post reply on HN