Name: nt126004 Date: 11/11/2002


FULL PRODUCT VERSION :
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)

FULL OPERATING SYSTEM VERSION :
Linux 2.4.19 #3 Wed Oct 23 09:02:02 EDT 2002 i686 unknown
  
ADDITIONAL OPERATING SYSTEMS :
compiled from sources

EXTRA RELEVANT SYSTEM CONFIGURATION :
nothing relevant

A DESCRIPTION OF THE PROBLEM :
Not a duplicate of bug 4106143
 
There is an inconsistency in the way javac compiles
classes that overide a method and change its return
type.
  
 
*Let's suppose you've got an interface like
javax.swing.ListModel
*You create a subclass that implements this interface :
public class MyClass implements ListModel
and you overide the method provided in ListModel :
public Object getElementAt( int index )
by a new method in MyClass :
public Integer getElementAt( int index )
 
javac sees no problem as it seems to be allowed to overid a
method and changing the return type for a subtype of the
return type of the overriden method (bug 4106143, 4144488)
 
So MyClass compiles just fine, there is no trouble.
 
But if someone uses your class with "polymorphism" for
example :
ListModel model = new MyClass();
and more easily here, if you give an instance of MyClass to
a JList with setModel()
then you'll get an AbstractMethodInvocationError at
runtime.
 
java will complain that it can't invoke the method
getElementAt, as if MyClass didn't have this method !
 
The bug I have reported is a VERY strange bug, please consider taking some
time to read the comments at the beggining of the test file because it is
really difficult to reproduce that bug.

In fact, I went too fast when I submitted the bug on sun's web site and I just
noticied this morning how strange the bug is.

javac compiles very well the classes that override methods from an interface
or an abstractclass : it does not allow to overide a method and change its
return type (for a subtype).....except if you inherit from a core java
interface or abstract class like javax.swing.ListModel

I hope you will understand my poor english in the comments of the attached
demo-file. Please if you don't, contact me again as I would really love to
see this bug swept out from jdk. I teach java and the bug was very difficult
to discover/understand for my students ... :)
 
long life to java technology !

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
please see bug description

EXPECTED VERSUS ACTUAL BEHAVIOR :
either I would like javac to complain or java to work.

REPRODUCIBILITY :
This bug can be reproduced always.

--------------- BEGIN SOURCE ------------------
import javax.swing.*;

/**
 * This file shows an important bug in the javac/java tools.
 * Please take some time for it, as it is really hard to understand.
 *
 * We have defined, in this file, 3 items:
 * -the interface Interface, which mimics the methods of javax.swing.ListModel
 * -the class AbstractClass, which mimic the behavior of javax.swing.AbstractLis
tModel. i.e, it is an abstract class
 * that implements ListModel but doesn't provide any overriden definition of the
 methods of ListModel we are interested in.
 * -the JavacTrouble class that will show the problem. This class has a main met
hod to instanciate itself and
 * overides all the methods of the interfaces Interface/ListModel (remember thos
e methods are the same).
 *
 * If you define that JavacTrouble extends AbstractClass, you'll get a compile-t
ime error, javac will recognize
 * that your "getElementAt" method must return an object and not a subclass of i
t.
 *
 * BUT, if you define that JavacTrouble extends AbstractListModel, you'll not ge
t this compile-time error.
 * Even if the problem is exactly the same one, I don't know why but it seems th
at there is less byte code verification
 * when extending the jdk classes.... So, you'll be able to compile your class E
VEN IF it will still have an abstract method:
 * ("getElementAt returning an Object") and you won't be able to use this as a m
odel for a jlist, you'll get
 * a runtime error about a abstract method invocation. (cause the jlist uses the
 missing method)
 *
 * to run the test: compile the class "as is" to get a compile error.
 * then uncomment the commented lines (the definition of the class and the conte
nt of the main)
 *
 * Please note that this happens only with javac, not with jikes. (ok, I suppose
 you don't really mind :) )
 * Moreover, it happened in jdk 1.4 and 1.4.1 and 1.4.1_01 but I don't know befo
re.
 * @author SN
 */

// uncomment this line and main class to compile, but not run.
//public class JavacTrouble extends AbstractListModel
public class JavacTrouble extends AbstractClass
{
  public JavacTrouble getElementAt( int index )
  {
    return this;
  }

  public int getSize()
  {
    return 4;
  }

  
  public static void main (String[] args)
  {
    /*
    * to show AbstractMethodError, uncomment this part.
    JFrame frame = new JFrame();
    JList list = new JList( new JavacTrouble() );
    frame.getContentPane().add( list );
    frame.pack();
    frame.show();
    */
  }
  
}//class JavacTrouble
 
interface Interface
{
  public int getSize();
  Object getElementAt( int index );
}//interface Interface

abstract class AbstractClass implements Interface
{
}//class AbstractClass

---------------- END SOURCE ------------------

CUSTOMER WORKAROUND :
Do not change the return type when overriding
(Review ID: 166247)
======================================================================