-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question about source compatibility check for interface extension #112
Comments
In addition, any idea why in the reporet japicmp mentions |
Bridge methods are created when you implement a parameterized interface like Node. If you now have a method that uses the parameter as argument for the method like Is one of your interfaces |
Ok thanks for the info. No, they're not parametrized:
|
So, would this be a bug? Thanks |
…compatible, #113 method that overrides in subinterface method from superinterface is no longer detected as source incompatible
Fixed this on the In case you want to try it out:
|
Thanks @siom79 I've just tried the develop branch and I still have a problem:
And in the diff file:
I don't see the star marker ('*') that indicates source incompatibility and I'm also not sure why this would be a source incompatibility. Thanks for fixing these 2 bugs quickly! |
The maven plugin also creates an XML file ( |
Here it is:
I see sourceCompatible=false in:
However old and new seems to be the same... Any idea? Thanks |
The issue was the following compatibility change on class level:
But adding an interface is only source incompatible, if your class does not implement all methods. But in your case you did implement I have fixed it on the |
Thanks again Martin. I've rebuilt and re-run japicmp and it's still failing for ExtensionId class. Here's what I get:
Basically nothing has changed. Note that I've git pulled and rebuilt twice to make sure I had the latest version... Any idea? Thanks |
Interesting output. What compiler do you use? As it looks, your compiler does not create the "bridge" method |
When I add the interface
|
I'm using Oracle's JDK 1.8.0_73-b02 (and thus Oracle's javac). |
I also tested it with Oracle's JDK but I got the same two methods as with the openjdk. Are you using any specific compiler flags? |
I'm using the following compiler flags:
Note: If you wish to try it:
Thanks |
Thank you for providing the details. With the help of them I could reproduce the problem. The root cause is of course not the java compiler. It generates as expected the synthetic bridge method:
The problem was the configuration option in your base pom.xml:
It was implemented as a pre-analysis filter and therefore removed the synthetic methods before the code that evaluates if all inherited abstract methods are implemented. I guess that you have set it due to the problem with I have corrected that on the |
Thanks a lot Martin for fixing this. I've also tested it and it works now indeed on xwiki-commons. Next step: I'll run it through the other XWiki repos (xwiki-rendering, xwiki-platform) and see how it goes. Regarding I'll let you know how it goes on xwiki-rendering and xwiki-platform. Thanks |
You don't need to enable |
Ok I understand, thanks for the explanation. |
@siom79 When do you think we could expect version 0.7.1 to be released? I'm eager to use it on XWiki :) Thanks |
Just released 0.7.1. It will take a few hours until it appears on Maven Central. |
great! Thanks |
Hi,
I'm wondering why the following is considered a breaking source compatibility change.
I have an interface Extension with
ExtensionFile getFile()
and I have another interface
LocalExtension
that extends it and I've addedLocalExtensionFile getFile()
in it, thus overriding the method in the base interface. The important part is thatLocalExtensionFile
extendExtensionFile
and thus any previous code usingLocalExtension#getFile()
would have returned anExtensionFile
before and the change is for me backward compatible.japicmp reports:
Is that correct in view of this?
Thanks!
The text was updated successfully, but these errors were encountered: