Comment 1 Adam Kiezun 2002-12-18 06:43:45 EST

>The tool found all classes that reference that method and
>replaced all but one correctly! Only the last one
>was not replaced at all!

for this one i will need a test case

Comment 2 Thorsten van Ellen 2002-12-20 09:02:39 EST

o.k. here is one:
(not yet compiled, but should be complete)

a/A.java:

package a;

public class A
{
  protected static void bla()
  {
    System.out.println("bla");
  }
}

aa/AA.java

package aa;

import a.A;

public class AA extends A
{
  public void blubb()
  {
    System.out.println("blubb");
    A.bla();
  };
}

b/B.java:

package b;

public class B
{
}

Explanation:

Class AA in package aa calls method bla in super class A in package a.
The reference to the method bla in Class A
from the method blubb in class AA is valid,
because AA extends A and therefore has access to bla!

Now, method bla should be moved 
from class A in package a to class B in package b.
Eclipse moves bla unchanged to class B!
The access level of the method bla remains PROTECTED!!!

The reference to the method bla in Class A
from the method blubb in class AA will be changed
from A.bla() to B.bla(), 
but class AA has no access to the protected method in class B!
And this is the problem!

best regards

Thorsten van Ellen

Comment 3 Adam Kiezun 2002-12-20 11:09:50 EST

cool - thanks
will have a look

Comment 4 Adam Kiezun 2002-12-20 11:16:51 EST

so the only problem is the access modifier, right?
making the method publi would make the compiler happy

if so, then we can fix it for M5 i guess

Comment 5 Adam Kiezun 2003-01-07 10:02:30 EST

i decided not to fix for M5 - it's a not very common case (accessing a protected
static member from a subclass) and you get a compiler error right away so it's
very easy to spot and fix

changing the visibility to public would be contrary to other places in Eclipse
refactoring.
so the only thing that could be done here is issuing a warning or an error
during precondition checking.
please reopen if you feel strongly.