# Refining The Return Type Of Java Methods Without Breaking Backwards-Compatibility

DevFeed: [Refining The Return Type Of Java Methods Without Breaking Backwards-Compatibility](<https://devfeed.tech/articles/refining-the-return-type-of-java-methods-without-breaking-backwards-compatibility-18862.md>)

Original publisher: [Read original article](<https://www.morling.dev/blog/refining-return-type-java-methods-without-breaking-backwards-compatibility/>)

Published: 2021-11-22T17:30:00Z

Content type: tutorial

Language: en

Sources: [Gunnar Morling](<https://devfeed.tech/sources/gunnar-morling.md>)

Topics: [Java](<https://devfeed.tech/topics/java.md>), [API](<https://devfeed.tech/topics/api.md>), [Library](<https://devfeed.tech/topics/library.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [compatibility](<https://devfeed.tech/tags/compatibility.md>), [java](<https://devfeed.tech/tags/java.md>), [library](<https://devfeed.tech/tags/library.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [source](<https://devfeed.tech/tags/source.md>)

## AI overview

This tutorial explains how refining a Java method's return type can break binary compatibility even when source code remains compatible. It examines the role of method return types in Java bytecode and presents the open-source Bridger tool as a way to preserve compatibility.

## Source excerpt

Table of Contents The Problem Bridge Methods to the Rescue Creating Bridge Methods Ourselves 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 open-source tool called Bridger.