Generics driving me crazy, for the fourth time

[Pat Farrell]

I've got the following interface and implementation:

public interface Node<T>  {
    /**
     * This returns the parent Tree, or null if this is the root.
     * @return the parent Tree, or null if this is the root.
     */	
    Node<T> getParent();

    /**
     * Allows you to set the parent Tree, or remove it with a null value.
     * @param parent the parent Tree, or remove it with a null value.
     */
    <T extends Node<T>> void setParent(Node<T> parent );
    /**
     * add node element to contained subtrees.
     * @param o
     * @return 
     */
    boolean add(Node<T> o);

}

public class AbstractNodeTree<T> implements Node<T>  {

    /** logger instance */
    private static final Logger aLog = Logger.getLogger(AbstractNodeTree.class);
/**  The parent Tree is stored here, if any. */
private Node<T> parent ;
private List<Node<T>> leaves = new ArrayList<Node<T>>();
    /** default constructor */
    public AbstractNodeTree() {
    }
    public Node<T> getParent() {
        return parent;
    }
    public <T extends Node<T>> void setParent(Node<T> arg) {
        parent = arg;
    }
    public boolean add(Node<T> o) {
        return leaves.add(o);
    }
}

Sure looks good to my eyes. But the compiler hates it. Specifically, I get:

Compiling 1 source file to /Users/pfarrell/sandbox/pdflib/build/classes
/Users/pfarrell/sandbox/pdflib/src/com/pfarrell/utils/collections/AbstractNodeTree.java:32: incompatible types
found   : com.pfarrell.utils.collections.Node<T>
required: com.pfarrell.utils.collections.Node<T>
        parent = arg;
1 error

Sure looks like "found" and "required" are the same to me. Any ideas what I'm doing wrong?

[Paul Clapham]

At line 12 of the interface you declare a type parameter T, and unfortunately you give it the same name as the type parameter in the declaration of the interface. So in a more readable form it's this:

<U extends Node<U>> void setParent(Node<U> parent );

Perhaps you might want this instead:

void setParent(Node<T extends Node<T>> parent );

That looks very much like what I ended up with when I tried to write a generic tree implementation.

[Pat Farrell]

Paul Clapham wrote:At line 12 of the interface you declare a type parameter T, and unfortunately you give it the same name as the type parameter in the declaration of the interface. So in a more readable form it's this:

<U extends Node<U>> void setParent(Node<U> parent );

I want the T to be the same one as the Type T of the thing, so we can have a Node<String> or a Node<Orange>

What then defines type "U"? I want it to be a Node<T> but I don't seem to know how to express that.

Paul Clapham wrote:Perhaps you might want this instead:

void setParent(Node<T extends Node<T>> parent );

This won't compile for me at all. Tons of errors, nearly every character in the generic part.

Compiling 1 source file to /Users/pfarrell/sandbox/pdflib/build/classes
/Users/pfarrell/sandbox/pdflib/src/com/pfarrell/utils/collections/Node.java:22: > expected
   void setParent(Node<T extends Node<T>> parent );
/Users/pfarrell/sandbox/pdflib/src/com/pfarrell/utils/collections/Node.java:22: ')' expected
   void setParent(Node<T extends Node<T>> parent );
/Users/pfarrell/sandbox/pdflib/src/com/pfarrell/utils/collections/Node.java:22: ';' expected
   void setParent(Node<T extends Node<T>> parent );
/Users/pfarrell/sandbox/pdflib/src/com/pfarrell/utils/collections/Node.java:22: <identifier> expected
   void setParent(Node<T extends Node<T>> parent );
/Users/pfarrell/sandbox/pdflib/src/com/pfarrell/utils/collections/Node.java:22: ';' expected
   void setParent(Node<T extends Node<T>> parent );
/Users/pfarrell/sandbox/pdflib/src/com/pfarrell/utils/collections/Node.java:22: illegal start of type
   void setParent(Node<T extends Node<T>> parent );

etc.....

Paul Clapham wrote:That looks very much like what I ended up with when I tried to write a generic tree implementation.

Did you succeed? or is this an hopeless effort? Would seem to be a fundamental data structure, should be easy to do. Famous last words.

[Stephan van Hulst]

Well, what is it you want? If you want the type of the parent to depend on whatever the type of the object you're passing to the setParent() method is, you can't do this in Java.

If you just want to keep a reference to the parent, and it doesn't matter what the type of the parent is, as long as it extends T, then your code should look like this:

public class AbstractNodeTree<T> implements Node<T>  {  
  /** logger instance */
  private static final Logger aLog = Logger.getLogger(AbstractNodeTree.class);

  /**  The parent Tree is stored here, if any. */ 
  private Node<? extends T> parent;

  private List<Node<T>> leaves = new ArrayList<>();

  /** default constructor */
  public AbstractNodeTree() {}

  public Node<? extends T> getParent() {  
    return parent;  
  }  

  public void setParent(Node<? extends T> arg) {  
    parent = arg;  
  }  

  public boolean add(Node<T> o) {  
    return leaves.add(o);  
  }  
} 

[Pat Farrell]

Stephan van Hulst wrote:Well, what is it you want? If you want the type of the parent to depend on whatever the type of the object you're passing to the setParent() method is, you can't do this in Java.

I'll try your code fragment.

I want the parent of a node of orange to be a Node<Orange>

I thought that if you define a tree of Oranges, you can have iterators that return Node<Orange> etc.

Its not that the invocation of the setParent() varies, when you define a bunch of Node<Orange>'s, then type safety would say you can only call
setParent() with a value that is a Node<Orange> But it doesn't seem to work,or my understanding is all out of sync with generics.

[Stephan van Hulst]

Well, if you want the parent of a tree of oranges to be a node of oranges, then you simply need a method signature:

public void setParent(Node<T> arg)

Unrelated: Why is the class called AbstractNodeTree and not just AbstractNode?

[Winston Gutkowski]

Pat Farrell wrote:I want the parent of a node of orange to be a Node<Orange>

I thought that if you define a tree of Oranges, you can have iterators that return Node<Orange> etc.

But unfortunately, that's not what you said with
<T extends Node<T>> void setParent(Node<T> parent );
mainly, as Stephan says, because you used the same generic variable (T) in the declaration.

Its not that the invocation of the setParent() varies, when you define a bunch of Node<Orange>'s, then type safety would say you can only call
setParent() with a value that is a Node<Orange> But it doesn't seem to work,or my understanding is all out of sync with generics.

If the only thing you wanted was a Node of the same type, you could have simply written:
void setParent(Node<T> parent);

Winston

[Pat Farrell]

Steve,

I swear that I tried that, and it didn't work.
But I've been beating my head against this for half a day, and I may be crazy.

Its called FooTree because when I wrote it, I thought that I needed both a Node and a NodeTree, and that I'd be subclassing a base AbstractNodeTree. But it looks like I don't need all that.

Current plan is that the root of any tree is just a Node<Foo> with a null parent.

99% of the time, Java Generics work great for me, but that other 1 percent, make my brain explode.

[Stephan van Hulst]

Pat Farrell wrote:I thought that I needed both a Node and a NodeTree

Haha, yeah that sounds familiar

[Winston Gutkowski]

Pat Farrell wrote:9(% of the time, Java Generics work great for me, but that other 1 percent, make my brain explode.

Wait until you get onto stuff like:
List<? extends Comparable<? super T>> list ...

Winston