Community
Participate
Working Groups
In the following example renaming foo will present two linked ui areas for the foo in the declaration of foo and in the wrong @see reference. After confirmation with return the changes at the @see reference will disappear. Expectation: no linked UI for wrong @see reference. /** * Breaking example */ package basic; public class TestArea { public void foo() { // Try to rename foo } /** * @see TestArea#foo this foo reference will have linked ui */ public void fooOther() { } }
Moving to UI for investigation. This might very well be a problem in core, but we will need some inputs as to what's going wrong in case.
Those references do match.
(In reply to Dani Megert from comment #3) > Those references do match. The issue I see is when renamed, the reference in Javadoc doesn't change. Is that expected?
(In reply to Jay Arthanareeswaran from comment #4) > (In reply to Dani Megert from comment #3) > > Those references do match. > > The issue I see is when renamed, the reference in Javadoc doesn't change. Is > that expected? Well, the problem is that the bug has a wrong summary and is not precise. The reference match and that is correct. There are two different rename commands. One for the file and one for the workspace. The latter seems to fail.
Actually I think the match is not correct since the reference is pointing to a field like: public int foo; If this field is added to the example the match does not any longer occur and the linked UI is not drawn.
(In reply to Stephanie Swiderski from comment #6) > Actually I think the match is not correct > since the reference is pointing to a field like: Nope, this is valid Javadoc for methods, e.g. if you don't want to restrict the Javadoc @see to a specific signature of #foo. There will be a problem for rename if there's more than one foo in the same file.
By Java Doc documentation: http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#tag @see class#field is different to @see class#method() and so I expect that renaming TestArea#foo() would not touch the comment /** * @see TestArea#foo this foo reference will have linked ui */
Ok my mistake: http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#see Here is desribed what you meant.
Then (In reply to Dani Megert from comment #7) > (In reply to Stephanie Swiderski from comment #6) > > Actually I think the match is not correct > > since the reference is pointing to a field like: > > Nope, this is valid Javadoc for methods, e.g. if you don't want to restrict > the Javadoc @see to a specific signature of #foo. > > There will be a problem for rename if there's more than one foo in the same > file. Maybe close this bug an reopen a different one for the failing rename command. I started the rename with rename refactoring hotkey and cursor on foo().
(In reply to Stephanie Swiderski from comment #10) > Then (In reply to Dani Megert from comment #7) > > (In reply to Stephanie Swiderski from comment #6) > > > Actually I think the match is not correct > > > since the reference is pointing to a field like: > > > > Nope, this is valid Javadoc for methods, e.g. if you don't want to restrict > > the Javadoc @see to a specific signature of #foo. > > > > There will be a problem for rename if there's more than one foo in the same > > file. > > Maybe close this bug an reopen a different one for the failing rename > command. > I started the rename with rename refactoring hotkey and cursor on foo(). It's fine - we can use that for the workspace rename.
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.
Still an issue using 4.12 M3.
