Closed garydgregory closed 8 months ago
Changing the return type from an interface to a concrete implementation causes the incompatibility METHOD_RETURN_TYPE_CHANGED
as now source code assigning the return value to another implementation of the interface won't work any longer.
This is already detected in the first run of japicmp, but the class is package protected and therefore filtered.
If you change the configuration of japicmp to package_protected
, you will see the change in the first run:
<plugin>
<groupId>com.github.siom79.japicmp</groupId>
<artifactId>japicmp-maven-plugin</artifactId>
<configuration>
<parameter>
<accessModifier>package_protected</accessModifier>
</parameter>
</configuration>
</plugin>
PS: The documentation is currently wrong, as the option is named there protected
and not package_protected
.
Uh? Please help me understand: If a released version of a library contains a package private class, then that class is NOT accessible to the outside world. So how can there be a break in compatibility for clients in the next version when that class is made public, no matter what changes?
You are right. When the class changes to public, all incompatibilities should be ignored.
You are right. When the class changes to public, all incompatibilities should be ignored.
Ah, thank you š š
I don't see how this breaks binary compatibility:
The failure does not make sense since no one outside the package could call C in version N. For example:
git clone -n https://gitbox.apache.org/repos/asf/commons-io.git
git checkout 877b9e3f5e553f8ad988b89b8adb6b93fa97a964
org.apache.commons.io.StreamIterator
publicmvn clean install -DskipTests japicmp:cmp -Dcommons.japicmp.version=0.18.1