From: Pavel Curtis <###@###.###>
This does not look like form output to me.


I believe that what follows is a bug in the JDK 1.0 `javac' compiler, the JDK
1.0 `java' interpreter, or both. Create the following four short files:

*** a/Main.java ------------------------------------------------------------

package a;

import b.Bar;
import java.applet.Applet;

public class Main extends Applet {
    public void start() {
        Foo f = new Bar();

        f.mumble();
    }
}

*** a/Foo.java -------------------------------------------------------------

package a;

public abstract class Foo {
    abstract void mumble();
}

*** b/Bar.java -------------------------------------------------------------

package b;

import a.Foo;

public class Bar extends Foo {
    public void mumble() {
        System.err.println("Got here.");
    }
}

*** test.html --------------------------------------------------------------

<applet code="a.Main" height=100 width=100></applet>

*** ------------------------------------------------------------------------

Your directory tree should now look like this:

        ./test.html
        ./a/Main.java
        ./a/Foo.java
        ./b/Bar.java

Run the appletviewer on test.html (I used a file: URL, but I don't think it
matters). Also run Netscape-2.0-FCS on it.

Under appletviewer you see `Got here.' on stderr. Under Netscape you see (in
the Java console) an `AbstractMethodError' when a.Main.start() tries to call
f.mumble().

I think that javac should be reporting an error in the compilation of
b/Bar.java, to the effect that Bar must be declared abstract because it isn't
providing an implementation for the Foo.mumble method, even though it *looks*
like Bar *is* providing such an implementation. The problem is that Foo's
mumble() method is not public, so it's not visible to Bar (which is in a
different package), so Bar *can't* override/implement it.

Regardless of this, though, the interpreter should be raising an error like
Netscape does when the call happens, since the visible `mumble()' method, the
one that Bar *did not* override/implement, is abstract.

This is a potentially serious security hole, since Bar, from a different
package, is being allowed to override a method it can't see, possibly upsetting
invariants in Foo's code.

Comments?

        Pavel Curtis
        Xerox PARC

[Sheri Good 03/13/97] Another user has reported what looks like the same issue:

Category: java
Subcategory: compiler
Bug/rfe/eou: bug
Synopsis: javac allows default access method to not be implemented in
derived class
Severity Impact: (internal)
Severity Functionality: (internal)
Priority: (internal)
Description: The following code should be rejected at compile-time:

    package p1;

    public abstract class Broken {
        abstract void f (); // default access
    }

    package p2;

    class TimeBomb extends p1.Broken {
        void f () {
        }
    }

because calling f() on a TimeBomb object via a Broken reference results
in an AbstractMethodError.
Work around: Don't use default access methods (which is good advice
anyway :-)
Comments: This is biggie, needs a posting on your 'Known Bugs' page!
customer_rec: new
Company: GMID sa
Employee: Roly Perera
Release: 1.1_Final
Hardware version: PC
O/S version: Win95
User Role: (internal)
User Type: (internal)
Sun Contact: (internal)
end_customer_rec: (internal)
BUG_END: