Bugzilla – Full Text Bug Listing
| Summary: | API tooling complains about adding method to an interface marked as @noimplement | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Thomas Watson <tjwatson> | ||||
| Component: | API Tools | Assignee: | Olivier Thomann <Olivier_Thomann> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | markus.kell.r, Michael_Rennie, mschorn.eclipse, Olivier_Thomann, remy.suen | ||||
| Version: | 3.6 | Flags: | Michael_Rennie:
review+
|
||||
| Target Milestone: | 3.7 M5 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Thomas Watson
I'll investigate once done with JDT issues. I also saw this first on a Mac, but since I didn't see it in my main workspace under Windows 7 (and I still don't see it there), I thought it was a setup issue. But now I can also reproduce on Windows 7 (with steps from comment 0). There are several things I would like to clarify. org.osgi.framework.BundleContext, org.osgi.framework.Bundle and org.osgi.framework.launch.Framework were not tagged with @noimplement in 3.6.0. Is this right? The error: The interface java.lang.Comparable adds method compareTo(T) to org.osgi.framework.Bundle that is not tagged as @noimplement actually makes sense since you added the Comparable interface to the Bundle class. So you add the compareTo(..) method as an API of the Bundle interface. That interface was not tagged as @noimplement in 3.6.0. So 3.6.0 implementors would be broken since they don't provide the compareTo(..) method. Same apply for the error reported against org.osgi.framework.launch.Framework since it inherits the compareTo(..) method from Bundle. The two methods org.osgi.framework.Bundle.adapt(Class<A>) and org.osgi.framework.Bundle.getDataFile(String) have been added to the bundle interface. Again since this interface was not tagged as @noimplement for 3.6.0, it would be a breakage to users that implemented it in 3.6.0. Same explanation applies for the type org.osgi.framework.BundleContext. The methods getBundle(String), getServiceReference(Class<S>), getServiceReferences(Class<S>, String) and registerService(Class<S>, S, Dictionary<String,?>) have been added to an interface not tagged as @noimplement in 3.6.0. I still need to investigate the two failures reported against org.eclipse.osgi.service.resolver.BundleDescription: - The interface org.osgi.framework.BundleReference adds method getBundle() to org.eclipse.osgi.service.resolver.BundleDescription that is not tagged as @noimplement - The interface org.osgi.framework.wiring.BundleRevision adds method getSymbolicName() to org.eclipse.osgi.service.resolver.BundleDescription that is not tagged as @noimplement Tom, do you agree with the fact that only the last two errors are suspicious, but I would say all others are expected. (In reply to comment #3) > Tom, do you agree with the fact that only the last two errors are suspicious, > but I would say all others are expected. So there is a check to see if @noimplement was added since the base line? And if @noimplement was added then any additions that break compatibility for implementing clients are flagged also? If this is true then I agree, only the last to errors seems suspicious and I should add a compatibility problem filter for the org.osgi.* packages since OSGi decided to add the appropriate @noimplement tags for R4.3. (In reply to comment #3) > > The error: > The interface java.lang.Comparable adds method compareTo(T) to > org.osgi.framework.Bundle that is not tagged as @noimplement > actually makes sense since you added the Comparable interface to the Bundle > class. So you add the compareTo(..) method as an API of the Bundle interface. > > That interface was not tagged as @noimplement in 3.6.0. So 3.6.0 implementors > would be broken since they don't provide the compareTo(..) method. > > Same apply for the error reported against org.osgi.framework.launch.Framework > since it inherits the compareTo(..) method from Bundle. > > The two methods org.osgi.framework.Bundle.adapt(Class<A>) and > org.osgi.framework.Bundle.getDataFile(String) have been added to the bundle > interface. Again since this interface was not tagged as @noimplement for 3.6.0, > it would be a breakage to users that implemented it in 3.6.0. > > Same explanation applies for the type org.osgi.framework.BundleContext. > The methods getBundle(String), getServiceReference(Class<S>), > getServiceReferences(Class<S>, String) and registerService(Class<S>, S, > Dictionary<String,?>) have been added to an interface not tagged as > @noimplement in 3.6.0. I would expect to see these errors as well, one error for the new restrictions and subsequent errors for any member (method / field) additions / changes. (In reply to comment #5) > I would expect to see these errors as well, one error for the new restrictions > and subsequent errors for any member (method / field) additions / changes. There were errors for the added restriction, but org.eclipse.osgi has already filters for these errors. This should be enough to also hide the other errors. (In reply to comment #5) > I would expect to see these errors as well, one error for the new restrictions > and subsequent errors for any member (method / field) additions / changes. I understand now. I had added a problem filter for the addition of the @noimplement tags added to the org.osgi.* classes. What confused me is I recently started seeing new errors about member (method / field) additions / changes to these org.osgi.* classes when I was not before. The errors on BundleDescription still look incorrect to me. (In reply to comment #7) > The errors on BundleDescription still look incorrect to me. I am looking at these ones. (In reply to comment #6) > There were errors for the added restriction, but org.eclipse.osgi has already > filters for these errors. This should be enough to also hide the other errors. This means I should use the current restrictions instead of the baseline's restrictions when new methods are added. I'll investigate this to make sure we don't miss any errors doing that. Right now the current behavior is acceptable except for the last two errors in BundleDescription. Patch under test. Targeting M5. Created attachment 184801 [details]
Proposed fix + regression tests
This patch removes secondary errors and fixes the two errors in BundleDescription.
Michael, could you please verify? I am having some errors running the tests, but I believe this is related to some errors while deleting resources and not directly related to this patch. Released for 3.7M5. Michael, please verify. looks good. *** Bug 332840 has been marked as a duplicate of this bug. *** |