This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 90769 - [Rename] Static import statement not modified
Summary: [Rename] Static import statement not modified
Status: VERIFIED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Refactoring (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Daniel Prusa
URL:
Keywords:
: 95959 111004 121058 (view as bug list)
Depends on: 89596 128815
Blocks:
  Show dependency tree
 
Reported: 2006-12-07 15:27 UTC by Jiri Prox
Modified: 2008-07-28 13:45 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Screen shot (60.73 KB, image/png)
2007-02-14 15:07 UTC, Jan Becicka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Prox 2006-12-07 15:27:51 UTC
NetBeans IDE Dev (Build 200612061900)
1.6.0-rc; Java HotSpot(TM) Client VM 1.6.0-rc-b104
Windows XP version 5.1 running on x86
en_US (nb); Cp1252

Static import not modified while renaming.

Steps to reproduce:
1) have class with static method
2) static import this method to another class (do not use *)
3) rename method
-> static import is not changed
Comment 1 Jan Becicka 2007-02-14 15:07:14 UTC
See attached screen shot. Problem is, that member select cannot be resolved to
proper element, namely selected node in Navigator.
Comment 2 Jan Becicka 2007-02-14 15:07:59 UTC
Created attachment 38496 [details]
Screen shot
Comment 3 Jan Becicka 2007-02-14 15:11:26 UTC
getElement(treePath) for treePath representing member select returns null.
Comment 4 Jan Lahoda 2007-02-15 08:50:39 UTC
Dusan, could you please take a look on this? Thanks.
Comment 5 Dusan Balek 2007-02-16 08:37:17 UTC
Unfortunately, it is as designed that static imports cannot be resoved to proper
Elements using Trees.getElement(...) method. Imagine the following case:

import static java.lang.Math.abs;

Element representing which of the abs(...) methods contained in the Math class
should be returned ???

Reassigning back to refactorig guru Honza.
Comment 6 Jan Becicka 2007-04-10 16:47:55 UTC
*** Issue 95959 has been marked as a duplicate of this issue. ***
Comment 7 Jan Becicka 2007-08-03 08:46:36 UTC
*** Issue 111004 has been marked as a duplicate of this issue. ***
Comment 8 Jan Becicka 2007-11-05 15:51:22 UTC
*** Issue 121058 has been marked as a duplicate of this issue. ***
Comment 9 fommil 2008-01-15 21:53:09 UTC
This would be so great... and appears to be trivial. Is it on any milestone? The situation I am thinking of is if I have used a method the old fashioned way... 
I'd like the hint to pop up and offer to convert it to a static import.
Comment 10 fommil 2008-01-15 22:04:44 UTC
sorry... ignore my last comment, it was meant for issue 89258. I don't know how it ended up here!
Comment 11 matthies 2008-01-21 14:40:27 UTC
What's the status of this? Target milestone is still set to 6.0.
Comment 12 Jan Becicka 2008-01-21 15:33:31 UTC
Still no progress
Comment 13 Daniel Prusa 2008-02-29 13:12:32 UTC
I have partially fixed the problem, now, static import is renamed when the imported element is unambiguously identified
by the name and there is at least one usage of the imported element in the given source file.
When issue 128815 is fixed the requirement on at least one usage presence will not be needed.
Comment 14 matthies 2008-03-10 19:09:34 UTC
This doesn't work for me. Here's my test case:

    package test;

    public class A
    {
        public static void foo() { }
    }

    package test;

    import static test.A.foo;

    public class B
    {
        { foo(); }
    }

Now rename foo() in A to bar(). This also renames the call in B, but it does not rename the static import line, causing 
two compile errors (one because the import referenced the non-existing "foo", another because "bar" is not being 
imported.)
The imported element ("foo") is unambiguously identified, isn't it?
Comment 15 matthies 2008-03-10 19:10:11 UTC
PS: Tested this with 6.1 Beta (Build 200803050202)
Comment 16 Daniel Prusa 2008-03-11 10:42:31 UTC
The fix is not part of 6.1 beta, it is only in development builds, the scenario described above should work there.
Comment 17 Jiri Prox 2008-04-11 01:48:04 UTC
moving opened issues from TM <= 6.1 to TM=Dev
Comment 18 Jan Pokorsky 2008-07-23 18:39:32 UTC
It works for me in NB 6.5. Closing as fixed.
Comment 19 Jiri Prox 2008-07-28 13:45:28 UTC
it works for me as well