Community
Participate
Working Groups
When searching for references for the following annotation: public @interface Expected { Class value(); } The match range for a use of this annotation is as follows: @Test <|>@Expected(Error.class) public void expectedException() { This is confusing since when the editor doesn't have focus the caret isn't shown and therefore the match isn't visible.
2 things here: 1) bug 93392: offset is wrongly set at source start of annotation instead of member pair value. I have a fix for this bug which should be released tomorrow morning 2) length=0: as said in bug 83230 comment 6, this is the expected behavior. Talking with markus about this, it seemed the simplest way for JDT/UI to handle method refactoring of implicit annotation method references. If you think this must be changed, here are other proposals we already talked about for this selection: a) select only the annotation type: @Test @<Expected>(Error.class)... b) select all the annotation: @Test <@Expected(Error.class)> c) select only the member pair value: @Test @Expected(<Error.class>) My preference was for c) but markus said it would need a parse to know whether the match contains an '=' or not to know if this was an implicit reference or not.
From the user angle I'm also in favor of c) but any non-empty selection would address the issue raised in the bug, i.e., you cannot see the match. Honoring the argument from Markus makes sense to me.
So, if I've well understood, we keep current implementation (ie. selection match length equals to 0). I keep this bug in REMIND status and will reopen it if several users feels unhappy with our choice on this point...
IMO the search match should carry information if the match is an implicit or explicit match. Asking JDT/UI to scan the document protion again to figure this out sounds strange. So I propose the following: - we add an API method isImplicitMatch which returns true in these cases. - the source range contains the length described in c.) Please note that this is an API addition and that we should keep in mind that this information would be very useful for constructors as well. I can accept that we only add this info for annotation members for 3.1 and leave the constructor as is. Comments ?
It's ok for me as this solve all existing problems. I have to figure out what would be the cost to have it also for implicit constructor, but for implicit member pair value, it can be done easily for M7. Jim, Following method would be added on SearchMatch: /** * Returns whether the associated element is implicit or not. * * Note that this piece of information is currently only implemented * for implicit member pair value in annotation. * * @return <code>true</code> if this match is associated to an implicit * member pair value in annation and <code>false</code> otherwise * @since 3.1 */ public final boolean isImplicit() { return this.implicit; } /** * Sets whether the associated element is implicit or not. * * @param implicit <code>true</code> if this match is associated to an implicit * member pair value in annation and <code>false</code> otherwise * @since 3.1 */ public final void setImplicit(boolean implicit) { this.implicit = implicit; } Is it an acceptable API change for 3.1?
Perhaps a change to getter javadoc comment: * @return <code>true</code> if this match is associated to an implicit * element and <code>false</code> otherwise and setter javadoc comment: * @param implicit <code>true</code> if this match is associated to an implicit * element and <code>false</code> otherwise
approved
Fixed and released in HEAD. Now length is set to member value length: @I(<12>). Note that this fixed is coupled with bug 93392 fix. [jdt-core-internal] Changes done in SearchMatch as described in comment 5 + MatchLocator.reportReference(ASTNode,...). Test case added in JavaSearchBugsTests
Verified for 3.1 M7 using build I20050509-2010 + jdt.core HEAD.
