Name: nt126004 Date: 07/15/2002


FULL PRODUCT VERSION :
[administrator@caplet jsrc]$ java -version
java version "1.4.1-beta"
Java(TM) 2 Runtime
Environment, Standard Edition (build 1.4.1-beta-b14)
Java HotSpot(TM) Client VM (build 1.4.1-
beta-b14, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version
5.00.2195]

ADDITIONAL OPERATING SYSTEMS :
I haven't tried it, but
I would be very surprised if this were OS dependent.


A DESCRIPTION OF THE PROBLEM :
When a concrete class (Class3 in the included example code) extends an
abstract class (Class2), which itself extends an abstract class
(Class1), and where Class1 declares and abstract method (zip()) that
Class2 implements and Class3 does not, there's normally no problem,
since there's nothing left for Class3 to implement.

But when zip() is
declared as package (ie, default) scope, and Class1 and Class2 are in one
package (test.foo), but Class3 is in another (test.bar), then the 1.4.1
javac compiler misses the fact that Class3 need not implement zip(), and
rejects it saying it should be abstract.

REGRESSION. Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Try compiling together the three included short classes. The 1.4.1 javac
will reject Class3 for the reasons explained in the Class2 class comment.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected, successful compilation, as I get with the 1.3.1
javac.

Actual: It fails to compile.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
c:/j2sdk1.4.1/bin/javac -g -classpath c:/j2sdk1.4.1/jre/lib/rt.jar;../../classes" -d
../../classes @files.tmp
test/bar/Class3.java:14: test.bar.Class3 should be declared
abstract; it does not define zip() in test.foo.Class1
public class Class3 extends Class2 {
       
^
1 error

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
See the javadoc class comment of Class2 below (it's short).

---------File test.foo.Class2:-------------

package test.foo;

// Copyright 2002 Combex, Inc. under the terms of the MIT X license
//
found at http://www.opensource.org/licenses/mit-license.html

/**
 * Demonstrates a
bug in Sun's j2sdk1.4.1's javac compiler.
 * <p>
 * This class itself compiles, as it should,
whether or not it is declared
 * abstract. However, if it is declared abstract, then its concrete
subclass,
 * {@link test.bar.Class3}, refuses to compile:
 * <pre>
 *
test/bar/Class3.java:14: test.bar.Class3 should be declared abstract; * it does not
define zip() in test.foo.Class1
 * public class Class3 extends Class2 {
 * ^
 * 1 error
 *
</pre>
 * This is wrong, because the abstract zip() from {@link Class1} is defined
 * here in
Class2. But perhaps because it is package (ie default) scope,
 * and Class3 is in a different
package, the compiler misses this when
 * Class2 is abstract.
 *
 * @author <a
href="mailto:###@###.###">Mark Miller</a>
 */
public abstract class Class2
extends Class1 {
    void zip() {}
}

----------------- file test.foo.Class1 ---------------
package test.foo;

//
Copyright 2002 Combex, Inc. under the terms of the MIT X license
// found at
http://www.opensource.org/licenses/mit-license.html

/**
 * Demonstrates a {@link
test.foo.Class2 bug} in Sun's j2sdk1.4.1's
 * javac compiler.
 *
 * @author <a
href="mailto:###@###.###">Mark Miller</a>
 */
public abstract class Class1 {
    
abstract void zip();
}

----------------- file test.bar.Class3 ------------------

package test.bar;

import
test.foo.Class2;

// Copyright 2002 Combex, Inc. under the terms of the MIT X license
//
found at http://www.opensource.org/licenses/mit-license.html

/**
 * Demonstrates a
{@link test.foo.Class2 bug} in Sun's j2sdk1.4.1's
 * javac compiler.
 *
 * @author <a
href="mailto:###@###.###">Mark Miller</a>
 */
public class Class3 extends Class2
{
}
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
In my actual case, I was able to declare the Class2-like class
(inappropriately) concrete, so I did that. Failing that, I expect that
one could declare the zip() method public or protected, or move Class3
into the same package as Class2 and Class1.

Release Regression From : 1.3.1
The above release value was the last known release where this
bug was known to work. Since then there has been a regression.

(Review ID: 159266)
======================================================================