Community
Participate
Working Groups
N20081020-2000 (worked in last I-build). 1. start fresh workspace 2. define API baseline to 3.4 3. check out org.eclipse.jdt.core from HEAD ==> tons of invalid API tooling errors Please ask for a rebuild as soon as this is fixed as it makes the API tooling in the I-build unusable.
> as it makes the API tooling in the I-build unusable. Should read: in the upcoming I-build (i.e. I20081021-0800).
Why are you saying these errors are invalid ?
>Why are you saying these errors are invalid ? Just look at them and look at the code (compare it to 3.4). I think you should be familiar enough with JDT Core code to see it ;-) Also, I get these in my .log (of the fresh workspace) !ENTRY org.eclipse.pde.api.tools 4 0 2008-10-21 15:42:52.691 !MESSAGE Could not locate method CompletionProposal()V !ENTRY org.eclipse.pde.api.tools 4 0 2008-10-21 15:42:52.910 !MESSAGE Could not locate method BuildContext()V I reported similar errors being logged from my dev workspace in bug 248122 but so far got no response from API tooling team regarding those errors.
I'll have a look at these errors today.
I mean these ones: !ENTRY org.eclipse.pde.api.tools 4 0 2008-10-21 15:42:52.691 !MESSAGE Could not locate method CompletionProposal()V !ENTRY org.eclipse.pde.api.tools 4 0 2008-10-21 15:42:52.910 !MESSAGE Could not locate method BuildContext()V The ones in JDT/Core are valid detections for me.
Talked to Olivier and looked at the code closer: those are real API breakages as the super types got removed and those had API relevant members that are now removed.
All errors I got are: The method org.eclipse.jdt.core.CompletionContext.setExpectedTypesSignatures(char[][]) has been removed The method org.eclipse.jdt.core.CompletionContext.setTokenRange(int, int) has been removed The method org.eclipse.jdt.core.CompletionContext.setTokenKind(int) has been removed The method org.eclipse.jdt.core.CompletionContext.setExtendedData(ITypeRoot, CompilationUnitDeclaration, LookupEnvironment, Scope, ASTNode, WorkingCopyOwner, CompletionParser) has been removed The method org.eclipse.jdt.core.CompletionContext.setJavadoc(int) has been removed The method org.eclipse.jdt.core.CompletionContext.setExtended() has been removed The method org.eclipse.jdt.core.CompletionContext.setOffset(int) has been removed The method org.eclipse.jdt.core.CompletionContext.setTokenRange(int, int, int) has been removed The method org.eclipse.jdt.core.CompletionContext.setToken(char[]) has been removed The method org.eclipse.jdt.core.CompletionContext.setTokenLocation(int) has been removed The method org.eclipse.jdt.core.CompletionContext.setExpectedTypesKeys(char[][]) has been removed The field org.eclipse.jdt.core.CompletionContext.expectedTypesKeys has been removed The field org.eclipse.jdt.core.CompletionContext.tokenKind has been removed The field org.eclipse.jdt.core.CompletionContext.isExtended has been removed The field org.eclipse.jdt.core.CompletionContext.expectedTypesSignatures has been removed The field org.eclipse.jdt.core.CompletionContext.token has been removed The field org.eclipse.jdt.core.CompletionContext.extendedContext has been removed The field org.eclipse.jdt.core.CompletionContext.tokenEnd has been removed The field org.eclipse.jdt.core.CompletionContext.tokenStart has been removed The field org.eclipse.jdt.core.CompletionContext.tokenLocation has been removed The field org.eclipse.jdt.core.CompletionContext.javadoc has been removed The field org.eclipse.jdt.core.CompletionContext.offset has been removed The method org.eclipse.jdt.core.CompletionProposal.setOriginalSignature(char[]) has been removed The restrictions have been changed for type org.eclipse.jdt.core.ITypeRoot The 'final' keyword has been added for the field org.eclipse.jdt.core.compiler.CompilationParticipant.READY_FOR_BUILD The 'final' keyword has been added for the field org.eclipse.jdt.core.compiler.CompilationParticipant.NEEDS_FULL_BUILD The method org.eclipse.jdt.core.search.FieldReferenceMatch.localElement(IJavaElement) has been removed The method org.eclipse.jdt.core.search.MethodReferenceMatch.localElement(IJavaElement) has been removed The method org.eclipse.jdt.core.search.PackageReferenceMatch.localElement(IJavaElement) has been removed The 'final' keyword has been added for the method org.eclipse.jdt.core.search.SearchDocument.getPath() The method org.eclipse.jdt.core.search.TypeReferenceMatch.localElement(IJavaElement) has been removed These ones: The restrictions have been changed for type org.eclipse.jdt.core.ITypeRoot The 'final' keyword has been added for the field org.eclipse.jdt.core.compiler.CompilationParticipant.READY_FOR_BUILD The 'final' keyword has been added for the field org.eclipse.jdt.core.compiler.CompilationParticipant.NEEDS_FULL_BUILD can be ignored as they are filtered out. For The restrictions have been changed for type org.eclipse.jdt.core.ITypeRoot the filter needs to be updated.
We will dicuss the general issue in API tooling of how to treat "internal" methods and fields. The compiler treats these as discouraged access, and in general Eclipse treats internals as internals. Such mixed API/non-API hierarchies present a challenge for API tooling. One proposal is to change the API problems reported. Instead of reporting an leaked superclass, we could report leaks on the actual methods and fields leaked. By default, in Eclipse, these could be warnings (or ignored). Similarly, we could have severity settings for when a leaked method/field on an internal supertype is removed.
>Talked to Olivier and looked at the code closer: those are real API breakages I was wrong and as Darin already pointed it will only break binary compatibility for those that did not obey to the API rules (http://www.eclipse.org/articles/article.php?file=Article-API-Use/index.html). I lowered the severity to 'major' as having errors in my workspace is still a major issue for me.
Olivier, this one seems like an API tooling bug: The 'final' keyword has been added for the method org.eclipse.jdt.core.search.SearchDocument.getPath() 'final' was there since 2004.
Created attachment 115789 [details] Fix for .api_filters
JDTCore should add filters for these, as these are just consequences of making the API cleaner (and removing internals from the picture).
>JDTCore should add filters for these, as these are just consequences of making >the API cleaner (and removing internals from the picture). Not that my fix only updates the existing stale filter and adding filters for the others would only be a temporary solution as we agreed that the current API tooling behavior of reporting errors is wrong: the Eclipse API rules cleary state that only members from API types are considered API members.
Note that these errors will be gone in the next build as we removed the compatibility check - see bug 251606. Instead we will have options to show what is leaking from the non-API supertypes (see bug 251610).
Created attachment 115914 [details] Temporary fix (while waiting for next I-build)
Temporary fix released for 3.5M3
Verified for 3.5M3 using I20081026-2000
