Java language RFE: Allow overriding to resolve return type conflict

I just submitted this overloading-related RFE to the Java Bug  
Database.  Thought others might find it interesting.  In Fortress, the  
three method declarations are valid due to the Meet Rule (15.6.4) and  
the Subtype Rule (which verifies that the return types are safe)  
(15.6.2).

—Dan

Begin forwarded message:

> From: Sun Microsystems <IncidentUpdateDaemon@...>
> Date: June 2, 2008 2:11:15 AM CDT
> To: dlsmith@...
> Subject: Re: (Incident Review ID: 1259860) Allow overriding to  
> resolve return type conflict
>
> --- Note: you can send us updates about your Incident ---
> --- by replying to this mail.  Place new information  ---
> --- above these lines.  Do not include attachments.   ---
> --- Our system ignores attachments and anything below ---
> --- these lines.                                      ---
>
> Hi Dan Smith,
>
> Thank you for taking the time to suggest this enhancement to the  
> Java Standard Edition.
>
> We have determined that this report is an RFE and has been entered  
> into our
> internal RFE tracking system under Bug Id: 6709429
>
> You can monitor this RFE on the Java Bug Database at:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6709429
>
> It may take a day or two before the RFE shows up in this external  
> database. As you are a member of the Sun Developer Network (SDN),  
> there are two additional options once the bug is visible.
>
> 1. Voting for the RFE
>   Click http://bugs.sun.com/bugdatabase/addVote.do?bug_id=6709429
>
> 2. Adding the report to your Bug Watch list.
>   You will receive an email notification when this RFE is updated.
>   Click http://bugs.sun.com/bugdatabase/addBugWatch.do?bug_id=6709429
>
> SDN members can obtain fully licensed Java IDEs for web and  
> enterprise development.  More information is at
http://developers.sun.com/prodtech/javatools/free/ 
> .
>
> We greatly appreciate your efforts in identifying areas in the Java  
> Standard Edition where we can improve upon and I would request you  
> to continue doing so.
>
> Regards,
> Nelson
>
> ~ 
> ~ 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> NOTICE: This message, including any attachments, is for the intended
> recipient(s) only.  If you are not the intended recipient(s), please
> reply to the sender, delete this message, and refrain from disclosing,
> copying, or distributing this message.
> ~ 
> ~ 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> --------------- Previous Messages ----------------
>
>
> --------------------- Report ---------------------
>
>      category : java
>   subcategory : specification
>       release : 6
>          type : rfe
>      synopsis : Allow overriding to resolve return type conflict
> customer name : Dan Smith
> customer mail : dlsmith@...
>        sdn id : dlsmith@...
>      language : en
>       company : Rice University
>      hardware : x86
>            os : windows_vista
>        bug id : 6709429
>  date created : Fri May 30 10:45:39 MST 2008
> date evaluated : Mon Jun 02 00:08:57 MST 2008
>   description :
> A DESCRIPTION OF THE REQUEST :
> I'd like to define a type hierarchy for which a child overrides a  
> method in two parents with different return types.  In general, this  
> looks like:
>
> interface A {}
> interface B {}
> interface C extends A, B {}
>
> interface X { A foo(); }
> interface Y { B foo(); }
> interface Z extends X, Y { C foo(); }
>
> Per JLS 8.4.8.4 (or perhaps an equivalent section describing  
> constraints on interface methods rather than class abstract  
> methods), this is illegal because no interface can extend both X and  
> Y: A is not substitutable for B, nor vice versa.  However, it is  
> impossible for any class that implements Z to violate type safety:  
> foo() will always return an A, as required by X, and will always  
> return a B, as required by Y.
>
>
>
> JUSTIFICATION :
> There are useful type hierarchies that can't be expressed without  
> relaxing this restriction.  For example:
>
> /** A set of pairs. */
> interface Relation<T1, T2> {
>  Relation<T2, T1> inverse();
> }
>
> /** A many-to-one relation. */
> interface FunctionalRelation<T1, T2> extends Relation<T1, T2> {
>  InjectiveRelation<T2, T1> inverse();
> }
>
> /** A one-to-many relation. */
> interface InjectiveRelation<T1, T2> extends Relation<T1, T2> {
>  FunctionalRelation<T2, T1> inverse();
> }
>
> interface OneToOneRelation<T1, T2>
> extends FunctionalRelation<T1, T2>, InjectiveRelation<T1, T2> {
>  OneToOneRelation<T2, T1> inverse();
> }
>
> On the flip side, I'm not aware of technical restrictions that make  
> this difficult to allow.  It's just a matter of relaxing the  
> overriding restriction.
>
>
>
> EXPECTED VERSUS ACTUAL BEHAVIOR :
> EXPECTED -
> The compiler accepts declarations like that for OneToOneRelation  
> without error.
> ACTUAL -
> javac produces an error:
>
> types InjectiveRelation<T1,T2> and FunctionalRelation<T1,T2> are  
> incompatible; both define inverse(), but with unrelated return types
>
>
>
> ---------- BEGIN SOURCE ----------
> public class TestOverriding {
>  interface Relation<T1, T2> {
>    Relation<T2, T1> inverse();
>  }
>  interface FunctionalRelation<T1, T2> extends Relation<T1, T2> {
>    InjectiveRelation<T2, T1> inverse();
>  }
>  interface InjectiveRelation<T1, T2> extends Relation<T1, T2> {
>    FunctionalRelation<T2, T1> inverse();
>  }
>  interface OneToOneRelation<T1, T2>
>      extends FunctionalRelation<T1, T2>, InjectiveRelation<T1, T2> {
>    OneToOneRelation<T2, T1> inverse();
>  }
> }
>
>
> ---------- END SOURCE ----------
>
> CUSTOMER SUBMITTED WORKAROUND :
> The return type of one of the conflicting interfaces must be  
> modified so that it is a supertype of the other, resulting in less  
> precise typing (and probably leading to subsequent downcasting).   
> For example, InjectiveRelation could simply inherit  
> Relation.inverse() with return type Relation<T2, T1>.