Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The concrete class compiles fine because B extends A, and since Java 5 a return type on a subclass can be a subclass of the return type on the superclass.</p> <p>As for the generic, I have hit the same wall, and you have two options that I know of.</p> <p>One is to paramaterize A:</p> <pre><code> public interface A&lt;T extends A&gt; extends Iterable&lt;T&gt; </code></pre> <p>then:</p> <pre><code>public class B implements A&lt;B&gt; </code></pre> <p>However, that has a disadvantage that you will need to give a parameter of A, instead of having it fixed, even if you want A:</p> <pre><code>private class NoOneSees implements A&lt;A&gt; </code></pre> <p>As to the question of if you actually want <code>Iterator&lt;B&gt;</code>, in the case of an Iterable, most likely that is preferable, and considering that these are interfaces, the need to redeclare the parameter is probably reasonable. It gets a little more complicated if you start inheriting concrete classes, and for things that have meaning other than an Iterable, where you may want covariance. For example:</p> <pre><code>public interface Blah&lt;T&gt; { void blah(T param); } public class Super implements Blah&lt;Super&gt; { public void blah(Super param) {} } public class Sub extends Super { public void blah(Super param) {} //Here you have to go with Super because Super is not paramaterized //to allow a Sub here and still be overriding the method. } </code></pre> <p>Similarly for covariance, you can't declare a variable of type <code>Iterator&lt;A&gt;</code> and then assign an <code>Iterator&lt;B&gt;</code> in it, even if B extends A.</p> <p>The other option is live with the fact that further implementation/subclasses will still reference A.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload