Support for Other JVM Languages about byte-buddy

[raphw]

Hei Sirinath,

I am glad you like Byte Buddy. I tested the API with both Scala and Groovy which are the two JVM languages that I occasunally use and those work just fine and especially in Scala, the DSL is very nice to read when ommitting dots and paranteses. And especially when using the more low-level APIs, it is not an accident that many methods of the functional interfaces in use are named apply.

Did you think about some specific language which would require improved support? If you have a language you would like to support, pull requests are very welcome!

Or did you speak about support for manipulating code written in other languages? In this case, Byte Buddy works with byte code which is language agnostic. With for example Scala, Byte Buddy behaves the same way as Java reflection does. As Byte Buddy ignores synthetic memebers in its default configuration, using Byte Buddy with other languages is however quite straight forward most of the time. A lot of code relies on reflection, thus languages often try to expose a Java-compatible interface what of course helps a lot.

All the best, Rafael

[sirinath]

Languages like Scala generate different names at the bytecode level. So you have to know exactly what something is complied into. It would be helpful if you can use the language level symbols which translate into the actual name / representation in bytecode. Also this is frequently changing in the case of Scala.

[raphw]

You are right, Scala is a problematic use-case in many relations. I do consider adding more Scala sensitive matchers at some point, the problem is however that these matchers would need to relate to a specific version of Scala as changes in the language would of course also affect the provided matchers.

I hope that I will find the time at some point to better analyze what changes are custom and to provide matchers that are least likely to fail. Up till now it is more or less the responsibility of the user to provide appropriate matchers or to, for example, only intercept methods on annotations instead of naming patterns when working with Scala.

[sirinath]

May be you can have a configuration file which match the Scala name with representation for the given version but transparent to the user. One this is defined user for the given version the user do not have to worry about what bytecode is generated underneath.

[raphw]

I thought about this and I came to the conclusion that this should not be a part of the core library but should rather be covered by an external library. The future of languages like Scala is uncertain and there are no guareantees about how their compilation is handled in the future.

If I added this fearure, I wanted to always be in sync with the compiler which is something I cannot promise. I therefore recommend Scala developers to use more explicit marks such as annotatations when identifying methods.