Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Patch

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Remko Popma <remko.popma AT azzurri.jp>
  • To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>, "Bradley S. Huffman" <hip AT a.cs.okstate.edu>
  • Cc: "xom-interest AT lists.ibiblio.org" <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] Patch
  • Date: Fri, 20 Sep 2002 03:54:44 +0900 (JST)

> The ParseException problem was easily found by switching to Java 1.4
> for the compile. What I don't understand is why the change was
> necessary. Shouldn't an overriding method be allowed to return a
> subclass of the return type of the original, overridden method? In
> this case, a ParseException is a Throwable, after all. Any idea
> what's going on here?

The java language spec doesn't allow a different return type
when overriding or hiding methods. It doesn't matter whether the return
type in the overriding method is a subclass of the return type of the
overridden method or not.

From: 8.4.6.3 Requirements in Overriding and Hiding
(http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#227965)

"If a method declaration overrides or hides the declaration of another
method,
then a compile-time error occurs if they have different return types (...)"


(see also:
8.4.6.4 Inheriting Methods with the Same Signature
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#227941)


I don't know if this could be one of the reasons for this rule, but
the spec also says that it breaks binary compatibility to change the result
type of a method.
(http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#45208)





Archive powered by MHonArc 2.6.24.

Top of Page