Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Byte Buddy is a code generation and manipulation library for Java

bytebuddy.net

Post reply on HN
Print view View original

41–50 of 52 posts

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

#41

Post by ackfoobar »

ActorNightly wrote: post #29
AdieuToLogic wrote: post #20

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…

> If you want speed

> If you want to be efficient

Funny that you assume the best position of the trade off continuum isn't somewhere in the middle for most people. Besides, for developer efficiency, I prefer a language where I don't have to constantly worry if the type system is defeated at runtime.

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

#42

Post by zappb »

kiicia wrote: post #32
pjmlp wrote: post #3

Note that Java now has its own API for this purpose. https://openjdk.org/jeps/484

Wasn’t there already like instrumentation api that was run via premain?

That is an even lower level API that lets you manipulate the bytecode as a byte array. You still need to parse it to do anything useful, hence libraries like ASM. And if you want to compile more code at runtime (or generate bytecode), you'll need some way to do that.

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

#43

Post by ActorNightly »

ackfoobar wrote: post #41
ActorNightly wrote: post #29

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…

> If you want speed > If you want to be efficient Funny that you assume the best position of the trade off continuum isn't somewhere in the middle for most people. Besides, for developer efficiency, I prefer a language where I don't have to constantly worry if the type system is defeated at runtime.

The best position in the middle is the combination of Python and C. I don't know why people are so aghast about writing small C programs, compiling them, and launching them with Python through an os call.

>I prefer a language where I don't have to constantly worry if the type system is defeated at runtime.

If you are doing this with Python, you are doing something very wrong, even without mypy. As for NodeJS, just use Typescript.

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

#44

Post by symbolicAGI »

wvenable wrote: post #28
symbolicAGI wrote: post #25

Earlier quoted context omitted.

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…

> A recent good reason for using Java is that frontier LLMs are trained with very large amounts of high quality enterprise Java source code. Where did it get it from?

GitHub public repositories mostly.

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

#45

Post by symbolicAGI »

gf000 wrote: post #33
symbolicAGI wrote: post #25

Earlier quoted context omitted.

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.

I first generate a specification JSON object from a text design narrative that lists fine-grained steps for each Java class that are constrained to be decomposed such that each fine grained step can be implemented as a static method in 20 lines of Java code or less. Likewise helper methods are similarly scoped to 20 LOC or less.

I also have a markdown-formatted document `core-programming-guidelines.md` that I include in the Claude Code code-generation prompt.

For example:

## Core Programming Principles

### Defensive Programming & Safety 1. *Use 'final' keyword aggressively* for method parameters, local variables, and class fields 2. *Null Safety*: Include null checks with Validate.notNull() and assertions for external calls 3. *Input Validation*: Validate all method parameters with clear preconditions using org.apache.commons.lang3.Validate

### Performance Optimization 1. *Collection Sizing*: Always provide calculated initial capacity for collections 2. *String Processing*: Use StringBuilder with pre-calculated capacity, avoid regex where possible and avoid `java.util.Scanner` where possible. 3. *Memory Management*: Clear large collections when done, reuse objects where appropriate

### Code Clarity & Documentation 1. *Naming Conventions*: Use descriptive names for variables, methods, and constants - All StringBuilder variables should be suffixed `Builder`. 2. *Documentation*: Comprehensive JavaDoc for all public, protected, and private methods 3. *Inline Comments*: Explain complex logic, algorithms, and business rules

### Modern Java 23 Features 1. *Text Blocks*: Use for multi-line string literals 2. *Pattern Matching*: Use where appropriate for cleaner code 3. *Records*: Use for immutable data carriers 4. *Enhanced Switch*: Use new switch expressions

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

#46

Post by wvenable »

symbolicAGI wrote: post #44
wvenable wrote: post #28

Earlier quoted context omitted.

> A recent good reason for using Java is that frontier LLMs are trained with very large amounts of high quality enterprise Java source code. Where did it get it from?

GitHub public repositories mostly.

I don't think Github is necessarily full of high quality enterprise Java software, is it?

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

#47

Post by AdieuToLogic »

ActorNightly wrote: post #43
ackfoobar wrote: post #41

Earlier quoted context omitted.

> If you want speed > If you want to be efficient Funny that you assume the best position of the trade off continuum isn't somewhere in the middle for most people. Besides, for developer efficiency, I prefer a language where I don't have to constantly worry if the type system is defeated at runtime.

The best position in the middle is the combination of Python and C. I don't know why people are so aghast about writing small C programs, compiling them, and launching them with Python through an os call. >I prefer a language where I don't have to constantly worry if the type system is defeated at runtime. If you are doing this with Python, you are doing something very wrong, even without mypy. As for NodeJS, just us…

> The best position in the middle is the combination of Python and C.

This is an opinion of which many would disagree, for various legitimate reasons, yet appears to be the polyglot approach you prefer. So let's briefly explore it.

> I don't know why people are so aghast about writing small C programs, compiling them, and launching them with Python through an os call.

There are significant limitations to using fork[0]/exec[1] as a general purpose component integration strategy, not the least of which is the inability of fine-grained bidirectional interactions.

A better "Python and C" integration option is to employ SWIG[2] to incorporate C/C++ libraries directly into the Python execution environment.

0 - https://man.freebsd.org/cgi/man.cgi?query=fork&apropos=0&sek...

1 - https://man.freebsd.org/cgi/man.cgi?query=execve&sektion=2&a...

2 - https://swig.org/

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

#48

Post by vips7L »

vips7L wrote: post #40
simon_void wrote: post #34

Earlier quoted context omitted.

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.

What I mean by that is this:

   val a: SomeType? = null
   // I’m forced to null check here
   if (a != null) {
       a.someMethodOnIt()
   }
   // But I don’t have to null check here
    a.someExtensionFn()
It’s weird.

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

#49

Post by izacus »

vips7L wrote: post #40
simon_void wrote: post #34

Earlier quoted context omitted.

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.

Yeah, extension functions are one of those features that went from 'oh, this is nice' to "this is so overused it's counterproductive".

It makes reading a lot of Kotlin source quite terrible.

Lately they've been shoveling a lot of similar magical "code comes from somewhere" features into a language, slowly giving it a C++ clutter type feel.

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

#50

Post by symbolicAGI »

wvenable wrote: post #46
symbolicAGI wrote: post #44

Earlier quoted context omitted.

GitHub public repositories mostly.

I don't think Github is necessarily full of high quality enterprise Java software, is it?

Grok says you are right (https://grok.com/share/c2hhcmQtMg%3D%3D_ddbace62-c299-4b7b-9...) however...

https://github.com/iluwatar/java-design-patterns

https://github.com/spring-projects/spring-framework

https://github.com/apache/kafka

https://github.com/neo4j

https://github.com/inforkgodara/store-poshttps://github.com/...

Post reply on HN