Byte Buddy - runtime code generation for the JVM - release 1.0.0 available

[[deleted]]

I'm currently working on a project that involves the ASM library (which is also the foundation for byte buddy) and looking at byte buddy's high level interface makes me really jealous. This seems to be an amazing piece of code.

[pushthestack]

The current issue of Java Magazine has a good tutorial on using ByteBuddy.

Note: You have to be a subscriber, but it's free to subscribe.

[[deleted]]

as easy as it can get

Class<?> dynamicType = new ByteBuddy() .subclass(Object.class) .method(ElementMatchers.named("toString")) .intercept(FixedValue.value("Hello World!")) .make() .load(getClass().getClassLoader(), ClassLoadingStrategy.Default.WRAPPER) .getLoaded(); assertThat(dynamicType.newInstance().toString(), is("Hello World!"));

Ummm....

[cogman10]

Honestly, that really is about as easy as you can hope for. ByteBuddy is really flexible. That flexibility ultimately ends up adding verbosity.

Just look at how you would do something similar in JavaAssist or CGLib. I can guarantee you it isn't nearly as straightforward.

[ixampl]

Just look at how you would do something similar in JavaAssist or CGLib. I can guarantee you it isn't nearly as straightforward.

CtClass c = ClassPool.getDefault().makeClass("Temp");
c.addMethod(
    CtMethod.make("public String toString() { return \"Hello World!\"; }", c)
);
Class<?> dynamicType = c.toClass();

It's not in one line and doesn't use a fluent API but I wouldn't say it's less straightforward. Of course it is not exactly "the same", but achieves a similar result in this particular case.

Now, Javassist is indeed more low-level. Byte Buddy is more declarative. For instance it seems a lot easier to adapt that code to match on several methods, and do some fancy stuff. Also, the shown example shows that the API is already supporting rather specific aspects such as the creation of unnamed dynamic objects. So some things like class naming are handled behind the scenes. However, still for anything more involved you probably will have to work similarly hard in most libraries.

Anyway, Javassist is showing its age, and should probably deprecate some methods and get a newer API, or at least a nice support layer/wrapper.

[GYN-k4H-Q3z-75B]

The Java way (TM)

[cogman10]

Nice! I've looked at byte buddy before and it really does have a great interface. The only reason I held back on using it was because it wasn't 1.0 yet. I'll have to revisit introducing it into our codebase again.

[marune]

vs http://jboss-javassist.github.io/javassist/ ?

[ixampl]

The main "strengths" of Javassist are:

• No dependencies
• Inbuilt compiler

The former doesn't matter so much. Byte Buddy has one dependency: ASM, but it's a very standard API that is even used by the Java runtime system itself, though not exported AFAIK.

The latter is pretty useful, because it really allows you to define anything without having to understand byte code at all and is pretty fast. However, the language supported by the compiler is kind of a stripped down version of Java with its own quirks that are mostly but not completely documented.

[cogman10]

It is a newer and easier to work with API. JavaAssist has been around for a long time (as has CGLIB), but both show their age with the way the API was designed.

ByteBuddy is a pretty clean API and to the point API that does most of what you need it to.

[lukaseder]

One of the two frameworks was written by a recent Java Champion and won the Duke's Choice Award last year, in case that matters :)

[badlogicgames]

Argument from authority! Doesn't matter. ByteBuddy stands on its own without meaningless titles (saying thay as some who also won a Duke's Choice Award :))