On Wed, 5 Oct 2022 at 17:07, Gary Gregory <garydgreg...@gmail.com> wrote:
> There is nothing at for > > https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-core/japicmp.html > > Thoughts? > Gary > Thanks for highlighting this. It is due to moving method implementations from a class to the declaring interface (default methods) and was discussed on the mailing list. JapiCmp is disabled for the core component. RevApi was added as a replacement and is enabled, see: https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-core/revapi-report.html Reason: The core module implements the interface definitions in the client-api module. This release changed the interface definitions to have default method implementations as the component is now using Java 8. This was done by moving the methods from an abstract base class in the core module to the client-api module. The methods in the core module have been removed as they are redundant (the code was exactly the same). JApiCmp does not like this and will fail the build. RevApi allows it [1] and you can see that in the report (search for java.method.movedToSuperClass under 'Changes Not Affecting The API'). I have tested binary compatibility for code built against release 1.4. If you run against core:1.5 and client-api:1.5 then the code is ok. But if you run against core:1.5 and client-api:1.4 then there will be a linkage error as the moved method is not available. This is why I wanted to create a BOM for the modules to be explicit that the versions have to be matched to maintain binary compatibility. I decided to disable JApiCmp only on this component as the configuration to add specific suppressions is limited in JApiCmp. The suppressions are global and in this case the removal of a method implementation (which is the error JApiCmp detects) is not something we want to suppress. If we wish to lower the upgrade path for users then the removed methods can be added back to the core module. This will add code redundancy. But I convinced myself with testing that the change is binary and source compatible. The issue seems to be in JApiCmp. Alex [1] https://revapi.org/revapi-java/0.27.0/differences.html#java.method.movedToSuperClass
