Comment by raphw

javassist takes strings containing Java code and compiles these strings at runtime. This makes it simple to use as every Java developer knows Java. Unfortunately, the javassist compiler lags a lot behind the actual javac compiler. For example, it does not support generics or even auto-boxing, not to speak of lambda expressions. Also, Strings are not type-safe what makes javassist code quite error prone. (It is the equivalent of concenating SQL strings together, with all the risks like foreign code injection.)

cglib allows you to register callbacks for an overridden class, similar to the JDK proxies. However, this requires that all class loaders know about cglib if they want to know these cglib-proxies as cglib-specific types are hard-coded into any generated class. Also, cglib only allows subclassing but not the rewrital of existing classes. Furthermore, the callbacks require any arguments to be boxed and registeres these boxed values into arrays. It turns out that cglib is not quite Just-In-Time-compiler friendly.

Byte Buddy works with annotations or its type-safe DSL and realizes its instrumentation mostly based on delegating to user code. This way, you can implement interceptors in any JVM language and you avoid dependencies on Byte Buddy within the generated classes (annotations are fortunately ignored by JVM class loaders if they cannot be resolved at load-time). This makes for example for better exception stack traces than when using "string code". Also, Byte Buddy avoids boxing by creating smarter objects for the interceptors and only creates those interceptors that are requested by annotated arguments, using dependency injection.

ASM or BCEL are rather byte code parser than code generation libraries. You need to have a clear concept of how byte code works in order to use them. Also, those libraries allow you to create "unverified code", i.e. you have to do a lot manually. Byte Buddy is itself built on top of ASM, you can even plug ASM code into Byte Buddy if you need to.