Community
Participate
Working Groups
The following methods need @noreference to indicate that they are not to be used by clients public IRequiredCapability applyOn(); public IRequiredCapability newValue(); public boolean matches(IRequiredCapability toMatch); IRequiredCapability is an internal class and should not be referenced anyways. This is a safe change for 3.6. (and pascal already did it). Opening bug report to clean up our API scans in the build.
Kim can you use this bug to exempt the API changes to the following from the api scan report? org.eclipse.equinox.p2.metadata.IRequirementChange#IRequiredCapability applyOn() org.eclipse.equinox.p2.metadata.IRequirementChange#boolean matches(IRequiredCapability) org.eclipse.equinox.p2.metadata.IRequirementChange#IRequiredCapability newValue()
Tom, it might be easier for you to update the files yourself. They are in the org.eclipse.releng project, in the apiexclude directory
(In reply to comment #2) > Tom, it might be easier for you to update the files yourself. They are in the > org.eclipse.releng project, in the apiexclude directory Thanks Kim. Will do.
*** Bug 305080 has been marked as a duplicate of this bug. ***
Pascal, I noticed that you added @noreference to org.eclipse.equinox.p2.metadata.IRequirementChange.equals(Object) Note that adding @noreference/@noextend/@noimplement will show as API changes. We need to get all of these documented in bug reports and get PMC approvals so we can exclude them from the API change scans. It seems a bit strange to add @noreference to the equals method. Why was that needed?
Because in the future I'm not sure about the ability to be able to support equality computation between those two objects.
(In reply to comment #6) > Because in the future I'm not sure about the ability to be able to support > equality computation between those two objects. I find it strange to add @noreference to a method that is overwritten from the Object class. In reality the equals method is going to be implicitly called all over the place if IRequirementChange is placed in Collection (in particular Set). John, do you see any issue here?
(In reply to comment #7) > (In reply to comment #6) > > Because in the future I'm not sure about the ability to be able to support > > equality computation between those two objects. > > I find it strange to add @noreference to a method that is overwritten from the > Object class. In reality the equals method is going to be implicitly called > all over the place if IRequirementChange is placed in Collection (in particular > Set). John, do you see any issue here? Yes, I don't think @noreference is useful here because it won't catch the most common uses (such as having the object in a collection). Also a client can always invoke ((Object)requirementChange).equals(..) and they will never hit the @noreference warning. I suggest if we aren't sure if the specification of equals will stay the same, or will be possible to support in the future, then just remove #equals from the interface. This way equality just isn't defined in the API and clients can't rely on its semantics. This way they can reference equals(...), but we can change the implementation in the future without breaking any of our API contracts.
Pascal, would you be willing to simply remove the equals method from the interface? From an API point of view that is the same as adding @noreference.
