Community
Participate
Working Groups
Quite a few (77 at the last count) warnings - clean these as and when time permits.
New Gerrit change created: https://git.eclipse.org/r/125011
Gerrit change https://git.eclipse.org/r/125011 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=34b0934a73e551da8850e794b900bc59e945583c
In my workspace o.e.jdt.core sports 31 warnings, most of which complain about extending s.t. marked @noextend, but since it's within the same plug-in that complaint is bogus. Similarly, some types are flagged as implementing a non-API type, where the super type is indeed API. Do others see this too? Are these bugs in API-tools?
(In reply to Stephan Herrmann from comment #3) > In my workspace o.e.jdt.core sports 31 warnings, most of which complain > about extending s.t. marked @noextend, but since it's within the same > plug-in that complaint is bogus. Similarly, some types are flagged as > implementing a non-API type, where the super type is indeed API. > > Do others see this too? Are these bugs in API-tools? Yes. I do see these warnings (the earlier commit addressed the baseline api stuff - these are still left). @Vikas: can you comment on the API-tools part?
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=479384
If the problem is due to bug 479384 and the code ( complaining the leak) was written before Jan 2017, adding api filter can be an option.
Two examples: org.eclipse.jdt.core.dom.Annotation implements org.eclipse.jdt.core.dom.IExtendedModifier While the latter is @noextend @noimplement I don't see why this should be relevant *within* JDT/Core. Still we get: "Annotation implements non-API interface IExtendedModifier" I see no reason why IExtendedModifier should be considered non-API org.eclipse.jdt.core.dom.AnonymousClassDeclaration extends org.eclipse.jdt.core.dom.ASTNode Same situation, just extends rather then implements, and a different error message: "AnonymousClassDeclaration leaks types by extending the type ASTNode tagged with '@noextend'" Both look like bugs in API tools to me.
The designers of IExtendedModifier wanted this interface to be @noimplement and @noextend so that probably they can add stuff without worrying about the clients. Now Annotation is implementing this from within this plugin. That is fine. But Annotation is a proper API out of this plugin. If now a breaking change is made to interface IExtendedModifier, that breaking change can be propagated to clients of Annotation.
ASTNode was designed to be no-extend for the clients. However AnonymousClassDeclaration extends ASTNode and since AnonymousClassDeclaration is not marked as no-extend, this provides a loop-hole to extend ASTNode indirectly for the clients( via AnonymousClassDeclaration )
Thanks, Vikas, much clearer now. So, if @noimplement and @noextend should normally propagate to sub-types, the "fix" would be to add similar annotations to all flagged types, right? But then this would be kind of a breaking change for those clients that already extend our classes without being told that they shouldn't. Still, maybe the warning messages could be improved so that ppl understand the issue without asking Vikas? :) Anyway, if that's the rationale, then API filters indeed sound like an option to me. OTOH, we could also push the burden of API filters down to (semi-legal) clients, to the benefit that they will know about the restriction that had been intended since day 1. Seeking advice from Dani ...
This was advertised in https://www.eclipse.org/eclipse/news/4.7/M5/ However a more clearer message is a good idea. For this case, I will recommend filter ( see comment#6).
(In reply to Stephan Herrmann from comment #10) > Thanks, Vikas, much clearer now. > > So, if @noimplement and @noextend should normally propagate to sub-types, > the "fix" would be to add similar annotations to all flagged types, right? > But then this would be kind of a breaking change for those clients that > already extend our classes without being told that they shouldn't. > > Still, maybe the warning messages could be improved so that ppl understand > the issue without asking Vikas? :) > > Anyway, if that's the rationale, then API filters indeed sound like an > option to me. > > OTOH, we could also push the burden of API filters down to (semi-legal) > clients, to the benefit that they will know about the restriction that had > been intended since day 1. > > > Seeking advice from Dani ... Sorry for being late. Very busy lately. Main problem here is that the leak detection got fixed after most of the (JDT Core) types were already created. Otherwise the developer would either have decided not to extend the type or to add @noextend. At this point the damage is done. Nothing can fix it, and adding @noextend at this point would be an immediate API breakage. What it means is that as soon as new abstract APIs are added to the superclasses it will cause compile errors on the client side. To avoid this the types that leak API will have to add an implementation. Therefore I would not suppress the warnings with a filter. The problem message is definitely wrong, e.g. "AnonymousClassDeclaration leaks types" is not correct. It should be something like "AnonymousClassDeclaration leaks the APIs from a super class". Finale note: Maybe the severity should have been set to 'Error'.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
outdated. please close.
