The semantics of method lookup, as determined by our current specs, and
implemented by Hotspot, differ from the behavior of the classic VM.
This breaks some user programs, and may require non-trivial work arounds
by customers.

We need to decide whether the spec should be changed (and it what way).
Here is an example, based on real customer code:

package testcase1;

public abstract class Base extends Object {

  abstract void printMessage();

  protected final void callMessage(){
    printMessage();
  }
}
----------------------------------------------
package testcase1;

public abstract class LocalTest extends Base {

  protected abstract void printMessage();

}
----------------------------------------------
package testcase2;
import testcase1.*;

public class RemoteTest extends LocalTest {
 
  protected void printMessage(){
    System.out.println("Hi");
  }

  public static void main(String[] args) {
    RemoteTest me = new RemoteTest();
    me.callMessage();
  }
}
----------------------------------------------

Hotspot throws an AbstractMethodError, while Classic prints out "Hi".
Fortunately, Hotspot actually does the right thing.

Main calls Base.callMessage, which does a lookup for printMessage.
It first finds RemoteTest.printMessage, but the resolved method
(Base.printMessage) is package private and thus not accessible from
RemoteTest, so the lookup continues. It then finds LocalTest.printMessage
which is protected and thus visible in RemoteTest, and calls that one,
resulting in the AbstractMethodError (see new JVM spec p. 291).

There are a variety of more or less exotic examples that relate to this issue,
see the coments section.


Background:

The root of the problem is whether package private methods in one package can be
overridden by subclasses declared in another package.

This problem has a long history. Briefly, the original JLS was flatly
self contradictory on the semantics of dynamic method dispatch.

JLS 6.6.5 partially describes the intent of the JLS authors by means of
an example. It indicates that a package private method may not be overridden
by a class in another package. It is
roughly consistent with the current (revised) spec. Guy and James have
confirmed that chapter 6 reflects their intent.

JLS 15.11.4.4 describes the precise semantics of method lookup. Applying
the algorithm of chapter 15 to the example in chapter 6 does not yield
the results claimed in chapter 6. It allows a package private method to be
overridden by a subclass in another package. This is viewed by some
as a violation of the security guarantees of the Java language. On the other
hand, it is the standard definition of method lookup, as understood by
programmers in C++, Simula, Smalltalk etc. It has been tried and tested for
over 30 years.

The classic VM's behavior has evolved over time. Essentially, a variety of
patches have been applied to make specific cases work a specific way. This
was done because it was unclear what the specification was (chapter 6 did not
give a complete specification). As a result, we don't know how to specify
a behavior that would be precisely compatible with the Java 2 VM.

In any event, different VM's have different behavior on this issue.
JDK 1.0 conforms to chapter 15. JDK 1.1 differs (and I'm not sure if 1.2 and 1.1
are the same), and Microsoft (if you care) behaves still differently.
I expect that VM's on small devices using interpreters will implement
chapter 15 semantics as well.

The current spec is based on JLS 8.4.6.
It prevents the override of package private methods by classes
in another package, yet allows a relatively simple specification. It also
has the advantage that it is still possible to produce a plausible
implementation based on lookup rather than Vtables. This is important for
small footprint implementations. It's main disadvantage is that it is non-local
and non-transitive. This makes for very non-intuitive behavior in some cases
(like the example in customer code).