Comments (15)
OK. It is helpful to know that these two issues are related though.
from japicmp.
Unfortunately it is not that easy, because we need to change the incompatibility for each occurrence. I think we need to change the list of incompatibilities from a pure enum
to an object, on which we can change the incompatibility level. :(
from japicmp.
But the method return type changed, didn't it? The change of the access modifier is not the problem.
from japicmp.
Yes, it changed, but it shouldn't be a problem as it was originally package-private
, or not?
Or do you have in mind split-package usage?
from japicmp.
This seems to duplicate #265
from japicmp.
@garydgregory the only reason I didn't mention it as a duplicate of #265 is the potential split-package usage of an existing package-private method (my case), while a private one (your case) wouldn't be affected.
from japicmp.
It is a difficult decision.
If you only have the point of view of the users of your library, then every package protected method should not be used (although some users might do it) and it becomes visible for your users with public access.
From a theoretical point of view, changing the return type and the modifier from package protected to public is incompatible with respect to inner package usage.
Back then I have assumed that the accessModifier
filter would solve the problem. But it looks like users only see the problem from their users point of view. Do we need a new option to solve this?
from japicmp.
A separate error that I can exclude in my config would work for me 👍
If there are split-package users that are impacted by this change, it means they are already dancing on the edge of brokenness and we don't provide support for such usage 😉
from japicmp.
Re-reading your last message, how is accessModifier
supposed to be used?
I set it to protected
(assuming it means it will analyze only elements that were protected and public before the change?) but I still received a METHOD_RETURN_TYPE_CHANGED error (see assertj/assertj@684063f).
from japicmp.
I thought about an implementation and as it looks, it might introduce a new concept. The point is that currently the relation between type of change (like e.g. METHOD_RETURN_TYPE_CHANGED
) and the incompatibility level was fix (see e.g. here).
Now we need something like METHOD_RETURN_TYPE_CHANGED
but because the access modifier also changed to more visible it is not binary incompatible. Not sure how to implement this in a concise way.
from japicmp.
My rough idea was to approach it in a way similar to #311.
I haven't looked at the code in detail yet, but I trust you can spot better than me whether this is feasible with such a strategy.
from japicmp.
Committed the changes mentioned above to a new branch. Will have to sleep a night, before I merge it.
from japicmp.
Thanks a lot for looking into it!
from japicmp.
Fixed with 0.19.0.
from japicmp.
Thank you!
from japicmp.
Related Issues (20)
- >=0.16.0: Cannot compare versions because the number of old versions is different than the number of new versions HOT 4
- Move of method to superclass with generics METHOD_REMOVED HOT 1
- New default method detected as METHOD_NEW_DEFAULT when BinaryIncompatible disabled and SourceIncompatible enabled HOT 1
- htmlTitle not actually added to html file HOT 2
- Changing default method to static should be separate case HOT 5
- Switch to Apache Groovy HOT 1
- False positive when making a package-private class public that already has a public static method's different return type HOT 5
- Maven plugin does not obey property japicmp.skip when generating reports. HOT 2
- False positive when on a final class protected method made into private HOT 1
- Regression CLASS_GENERIC_TEMPLATE_CHANGED HOT 2
- Questions about the mechanism of binary compatibility checks HOT 2
- some newer kotlin changes show up as a binary string HOT 3
- Take `transient` modifier into account
- have some sort of "warn" level HOT 1
- Do not mark class as changed in case of synthetic member
- JApiCmpArchive should support byte arrays
- Take `volatile` modifier into account
- Take changes to annotations into account HOT 4
- Annotation @XmlAttribute for type in JApiCompatibilityChange HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from japicmp.