If you work on any kind of software library,
ensuring backwards-compatibility is a key concern:
if there’s one thing which users really dislike, it is breaking changes in a new version of a library.
The rules of what can (and cannot) be changed in a Java API without breaking existing consumers are well defined in the Java language specification (JLS),
but things can get pretty interesting in certain corner cases.


The Eclipse team provides a comprehensive overview about API evolution guidelines in their wiki.
When I shared the link to this great resource on Twitter the other day,
I received an interesting reply from Lukas Eder:



I wish Java had a few tools to prevent some cases of binary compatibility breakages. E.g. when refining a method return type, I’d like to keep the old method around in byte code (but not in source code).


I think kotlin has such tools?



In the remainder of this post,
I’d like to provide some more insight into that problem mentioned by Lukas,
and how it can be addressed using an…

If you work on any kind of software library,
ensuring backwards-compatibility is a key concern:
if there’s one thing which users really dislike, it is breaking changes in a new version of a library.
The rules of what can (and cannot) be changed in a Java API without breaking existing consumers are well defined in the Java language specification (JLS),
but things can get pretty interesting in certain corner cases.


The Eclipse team provides a comprehensive overview about API evolution guidelines in their wiki.
When I shared the link to this great resource on Twitter the other day,
I received an interesting reply from Lukas Eder:



I wish Java had a few tools to prevent some cases of binary compatibility breakages. E.g. when refining a method return type, I’d like to keep the old method around in byte code (but not in source code).


I think kotlin has such tools?



In the remainder of this post,
I’d like to provide some more insight into that problem mentioned by Lukas,
and how it can be addressed using an…