Name: rm29839			Date: 01/22/98


According to the actual Java specification, the following code would produce a compiler error:

<code>
abstract class Aclass
{
  public abstract Number giveMeANumber();
}

class ASubClass extends Aclass
{
  public Integer giveMeANumber()
  {return new Integer(8);}
}
</code>

I understand that it is an error to overload a method with an other one with the same signature but a totally different return type.
 But it���s not clear to me why we are not allowed to change the return type in this particular case, since Integer is a subclass of
 Number. If a method calling AClass.giveMeANumber() was expecting a Number object, I see no objection to giving it an Integer
 object. In fact, I see some advantage in allowing this kind of change. The following discussion gives two examples:


ADVANTAGE IN THE OVERLOADED clone() METHODS:
When implementing the clone method, it would allow us to cast the cloned object to the right type. It may help to trap some
 errors at compile time. The following code give an example with the two classes above:


/* Legal, but may throw a ClassCastException at run time */
void check(AClass c)
{Float f=(Float) c.giveMeANumber();}

/* Should produce a compile time error */
void check(ASubClass c)
{Float f=(Float) c.giveMeANumber();}

If you change the return type of all clone() methods in the Java library to the right type, it seem to me that it would not break
 the backward compatibility, except in the case of obvious programming error. In those cases, this change will help to catch at 
compile time some errors which are actually caught only at run time. Nevertheless, I fully understand that you want to be very 
careful about any language change.


ADVANTAGE IN THE java.text.Format.parseObject(String) METHOD:
The java.text.NumberFormat.parse(String) method is implemented as below:

<code>
public Number parse(String text) throws ParseException {
    ParsePosition status=new ParsePosition(0);
    Number result=parse(text, status);
    if (status.index==0)
        throw new ParseException("Unparseable number: \""+text+"\"", 0);
    return result;
}
</code>

In comparison, the java.text.Format.parseObject(String) is implemented in a similar way, except that its error message is 
more general (and less explicit):

<code>
public Object parseObject(String text) throws ParseException {
    ParsePosition status=new ParsePosition(0);
    Object result=parseObject(text, status);
    if (status.index==0)
        throw new ParseException("Format.parseObject(String) failed", 0);
    return result;
}
</code>

If it was allowed to overload an "Object parse(String)" method in the Format class with the actual "Number parse(String)" 
method in the NumberFormat class, it will allow you to rename the actual "parseObject" method in the Format class to "parse", 
and to deprecate the old "parseObject" method. We would get a simpler interface and better error messages when the method 
throws a ParseException. Actually, the parseObject method has no way to produce better error messages than "Parse failed".

Maybe I misunderstand the problem. So I will not be surprised if this feature request get the "Closed, will not be fixed" status. 
But I hope you may consider it as one more vote for some language improvement. I would also like to support the feature requests 
4093718 (the "const" keyword), 4087427 (operators overloading) and 4066667 (complex primitives). Thank you.
(Review ID: 23140)
======================================================================