Interview with Rafael Winterhalter



1. In a few words, how was Byte Buddy born?
Byte Buddy was born out of my own need for another open source library which needed to create proxies in a slightly different way as the then existing solutions offered. As so often, I started out with a simple prototype that solved this exact need but moved it to its own library later which is now known as Byte Buddy and which is of course much richer in features than what I originally intended.

2. Were you always interested in low level Java (bytecode and its manipulation), or do you also like doing something else with Java?
I was educated in (theoretical) economics and had to run a lot of simulations as part of my studies. In modern economics, we try to emulate markets with models that can no longer be solved numerically but are simulated instead. These simulations often run over days and it is therefore crucial to write efficient code that quickly drives you down the rabbit hole. When I first worked with Java, looking into the JVM at this level was just a natural step.

3. ByteBuddy is really vastly used across different tools and frameworks. Were there situations, when you wanted to introduce a really cool new feature, but it was a breaking change, and the impact would have been too big?
In the beginning, I would know all users and every time I released a breaking change, I would simply send pull requests along with the update for all of them. Of course, this is no longer possible. Fortunately, the user base of Byte Buddy only grew two years after the first beta version was released. As things stand, I am very careful with changes and have a lot of regression tests. And thanks to the modular API, I can often add features without even touching existing code.

4. How do you handle this kind of situation?
It is a case to case decision. If a feature for example only affects Java agents, it is often a safe change as users need to isolate their copy of Byte Buddy anyways, via shading or a separate class loader. Agents do not control the class path and cannot assume that their version of Byte Buddy would not be superseded with an older version that was already added to the JVM. But if an API affects a proxy generator, I would not even consider touching it. If I ever wanted to do an overhaul, a theoretical Byte Buddy v2. would get a different group id and namespace, otherwise this would be too disturbing for the ecosystem.

Thank you very much, Rafael! See you soon in Sofia!