You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Alex Herbert <al...@gmail.com> on 2022/05/09 12:58:38 UTC
[parent][rng] japicmp binary compatibility for interface default methods
I would like to change some current interface methods in Commons RNG to
have a default implementation. This is detected as not allowed by the
current japicmp settings in commons parent. I think the settings should be
updated.
The default settings for japicmp state that default methods introduced into
an interface break binary (and source) compatibility. This is entry
METHOD_NEW_DEFAULT in the japicmp-maven-plugin documentation here [1]. This
is not correct (and is the reason for default methods in interfaces) and
was fixed in commons parent in commit d5d3a1b [2].
Changing an existing method in an interface to have a default
implementation is also listed as not compatible in japicmp
(entry METHOD_ABSTRACT_NOW_DEFAULT). However I cannot prove that this does
break binary (or functional) compatibility. I've tested execution of
classes compiled against an old version of the interface when the classpath
includes a new version with a default implementation. It all runs as
expected, i.e. existing implementations of interface methods are invoked.
I ran some other tools listed on the japicmp page against the code where
one interface method has been changed from abstract to default.
Java API Compliance Checker [3]
revapi [4]
If I do something wrong such as removing an interface method then the tools
list compatibility as broken. If I add a default implementation to an
interface method both these tools do not raise an error.
The change is reported by the Java API Compliance Checker and is listed as
compatible. However I cannot get revapi to report that the interface
methods now have a default implementation. The revapi check is Method Now
Default and is listed as a transparent change [5]. The omission from the
report may be due to some settings I did not find in the maven plugin.
I suggest updating commons parent to allow METHOD_ABSTRACT_NOW_DEFAULT to
be a non-breaking change.
Alex
[1] https://siom79.github.io/japicmp/MavenPlugin.html
[2]
https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=d5d3a1bcb03cf3c2bb50e66786ce73e6779fa62d
[3] http://ispras.linuxbase.org/index.php/Java_API_Compliance_Checker
[4] https://revapi.org/revapi-site/main/index.html
[5]
https://revapi.org/revapi-java/0.26.1/differences.html#java.method.nowDefault
Re: [parent][rng] japicmp binary compatibility for interface default methods
Posted by Alex Herbert <al...@gmail.com>.
On Tue, 10 May 2022 at 14:59, Gilles Sadowski <gi...@gmail.com> wrote:
> Le mar. 10 mai 2022 à 09:53, Alex Herbert <al...@gmail.com> a
> écrit :
> >
> > On Tue, 10 May 2022 at 02:32, Matt Juntunen <ma...@gmail.com>
> > wrote:
> >
> > > Sounds reasonable to me. Are there any arguments against this change
> > > other than the fact that it is not a japicmp default setting?
> > >
> >
> > I do not know why the setting default is at the current value. Unlike the
> > documentation for revapi there is limited explanation of the default
> > settings in japicmp and why compatibility for binary or source will be
> > broken. It may be that the developer explicitly wished to be informed of
> > additions to interfaces.
> >
> > Since this is unlikely to affect much at all it may be fine left as is in
> > commons parent. The configuration can be added to the relevant POM in
> > Commons RNG.
>
> IIUC, it should be the other way around: If BC is not broken, the
> common Commons settings should not report otherwise, and if
> some specific component has additional requirements, let it modify
> its own POM.
>
>
The original change was added to commons parent by Gary Gregory, I presume
because a downstream project added a default method to an interface and
japicmp complained. This must be the first instance in commons where a
default implementation is added for an existing interface method. I can add
the change to CP when I know it is definitely correct.
I have finished the implementation in RNG. I am going through testing the
snapshot with code that was built against the previous version.
Alex
Re: [parent][rng] japicmp binary compatibility for interface default methods
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mar. 10 mai 2022 à 09:53, Alex Herbert <al...@gmail.com> a écrit :
>
> On Tue, 10 May 2022 at 02:32, Matt Juntunen <ma...@gmail.com>
> wrote:
>
> > Sounds reasonable to me. Are there any arguments against this change
> > other than the fact that it is not a japicmp default setting?
> >
>
> I do not know why the setting default is at the current value. Unlike the
> documentation for revapi there is limited explanation of the default
> settings in japicmp and why compatibility for binary or source will be
> broken. It may be that the developer explicitly wished to be informed of
> additions to interfaces.
>
> Since this is unlikely to affect much at all it may be fine left as is in
> commons parent. The configuration can be added to the relevant POM in
> Commons RNG.
IIUC, it should be the other way around: If BC is not broken, the
common Commons settings should not report otherwise, and if
some specific component has additional requirements, let it modify
its own POM.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [parent][rng] japicmp binary compatibility for interface default methods
Posted by Alex Herbert <al...@gmail.com>.
On Tue, 10 May 2022 at 02:32, Matt Juntunen <ma...@gmail.com>
wrote:
> Sounds reasonable to me. Are there any arguments against this change
> other than the fact that it is not a japicmp default setting?
>
I do not know why the setting default is at the current value. Unlike the
documentation for revapi there is limited explanation of the default
settings in japicmp and why compatibility for binary or source will be
broken. It may be that the developer explicitly wished to be informed of
additions to interfaces.
Since this is unlikely to affect much at all it may be fine left as is in
commons parent. The configuration can be added to the relevant POM in
Commons RNG.
Alex
Re: [parent][rng] japicmp binary compatibility for interface default methods
Posted by Matt Juntunen <ma...@gmail.com>.
Sounds reasonable to me. Are there any arguments against this change
other than the fact that it is not a japicmp default setting?
-Matt J
On Mon, May 9, 2022 at 8:59 AM Alex Herbert <al...@gmail.com> wrote:
>
> I would like to change some current interface methods in Commons RNG to
> have a default implementation. This is detected as not allowed by the
> current japicmp settings in commons parent. I think the settings should be
> updated.
>
> The default settings for japicmp state that default methods introduced into
> an interface break binary (and source) compatibility. This is entry
> METHOD_NEW_DEFAULT in the japicmp-maven-plugin documentation here [1]. This
> is not correct (and is the reason for default methods in interfaces) and
> was fixed in commons parent in commit d5d3a1b [2].
>
> Changing an existing method in an interface to have a default
> implementation is also listed as not compatible in japicmp
> (entry METHOD_ABSTRACT_NOW_DEFAULT). However I cannot prove that this does
> break binary (or functional) compatibility. I've tested execution of
> classes compiled against an old version of the interface when the classpath
> includes a new version with a default implementation. It all runs as
> expected, i.e. existing implementations of interface methods are invoked.
>
> I ran some other tools listed on the japicmp page against the code where
> one interface method has been changed from abstract to default.
>
> Java API Compliance Checker [3]
> revapi [4]
>
> If I do something wrong such as removing an interface method then the tools
> list compatibility as broken. If I add a default implementation to an
> interface method both these tools do not raise an error.
>
> The change is reported by the Java API Compliance Checker and is listed as
> compatible. However I cannot get revapi to report that the interface
> methods now have a default implementation. The revapi check is Method Now
> Default and is listed as a transparent change [5]. The omission from the
> report may be due to some settings I did not find in the maven plugin.
>
> I suggest updating commons parent to allow METHOD_ABSTRACT_NOW_DEFAULT to
> be a non-breaking change.
>
> Alex
>
> [1] https://siom79.github.io/japicmp/MavenPlugin.html
> [2]
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=d5d3a1bcb03cf3c2bb50e66786ce73e6779fa62d
> [3] http://ispras.linuxbase.org/index.php/Java_API_Compliance_Checker
> [4] https://revapi.org/revapi-site/main/index.html
> [5]
> https://revapi.org/revapi-java/0.26.1/differences.html#java.method.nowDefault
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org