Comparing generic types (extends vs implements and within the context of LinkedList using nodes private class)

I have a standard LinkedList class with nodes that have data fields of generic type and I'm trying to compare them but not sure how I should go about it.

My node class

private static class Node<E> 
{
	E data;
	Node<E> prev;
	Node<E> next;
}

Basically, I'm trying to do

if(nodeA.data > newData)
     //do something

Should I be doing something like

public class MyLinkedList<E extends Comparable <E>>

or
public class MyLinkedList<E> implements Comparable <E>

And for both ways, do I implement my own compareTo method?
I've tried this but the compareTo usually looks like

public int compareTo(E data)
{
	if(this > data)
		return 1;
    //add others
}

And here, the 'this' would refer to my LinkedList class, not the generic type E.

Thank you

If you want to compare the data contained in the node, then public class MyLinkedList<E extends Comparable<E>> is the way to go, since this guarantees that the generic type E provides a compareTo(...)-method. In this case, implementing the compareTo-method is a job for the developer writing the type.

If you define public class MyLinkedList<E> implements Comparable<E> then you make a node comparable to E, but since E is unbound, it basically gets erased to Object <s>and this really would not give you any real possibility to compare objects</s>. Since one can access the variable of type E only as if it were an Object, one basically has no access to relevant information to implement a meaningful order. I would question such an order, or at least ask for the specific use case for this order.

Two Remarks:

Since Java does not support operator overloading, one cannot write

nodeA.data > something

but call the compareTo-Method and evaluate its return value, e.g.:

nodeA.data.compareTo(something) > 0

There is also another way to allow types that do not implement Comparable by enforcing that a Comparator<E> is passed along. PriorityQueue uses this approach.

Unless I've completely misunderstood your question, then since you said&hellip;

> Basically, I'm trying to do
>
> if(nodeA.data > newData)
> //do something

&hellip;then to me it makes more sense to have the type parameter of your Node implement Comparable instead of the one of your List&hellip;

public class LinkedList<E>{ 

    public static class Node<E extends Comparable<E>> {

        E data;

        Node<E> next;

        Node<E> prev;


        Node(Node<E> prev, E element, Node<E> next) {

            this.data = element;

            this.next = next;

            this.prev = prev;

        }
    
        public E getData( ){ return this.data; }

    }
}

Then whatever your data is, it would have to implement Comparable&hellip;

public class Foo implements Comparable<Foo>{ 
    
    private int x;
    
    public Foo(int x){ this.x = x; }
    
    public int compareTo(Foo that){ 
        return this.x < that.x ? -1 : this.x == that.x ? 0 : 1;
    }
}

&hellip;allowing you to do something closer to what you specified with your if(nodeA.data > newData) pseudocode&hellip;

public class DeduperAnswer{ 
    
    static public void main(String... args){ 
        
        LinkedList.Node<Foo> node1 = new LinkedList.Node<>(null, new Foo(10), null);
        LinkedList.Node<Foo> node2 = new LinkedList.Node<>(null, new Foo(20), null);
 
        if (node2.getData().compareTo(node1.getData()) > 0){ 
            /* ...this is NOT how you'd use it, of course...*/
        }
    }
}

You can see a quick and dirty working example here.

TL;DR: It is absolutely possible to compare two Comparable parameterized instantiations of some generic type T<E> regardless of type erasure.

One answer said&hellip;

> „&hellip;but since E is unbound, it basically gets erased to Object and this really would not give you any real possibility to compare objects&hellip;“

Type erasure happens. However — at least in the context of the quoted hypothesis above — type erasure is not the issue in that context. The issue in that context and in that of the original question is: E will ultimately be some specific type when a given parameterized type is instantiated by an actual type argument at the use site.

@Turing85's hypothesis raises this question:

Q: Whatever the ultimate type of E is, is it mandatory for it to implement Comparable in order for there to be „any real possibility to compare objects“?

A: No. In the context of the original question, it's not about E implementing Comparable. In that context, it's about MyLinkedList implementing Comparable.

Declaring a generic class with an unbound type parameter E does not preclude the possibility to compare objects. For example there could be some use case where it's necessary to have MyLinkedList<MyLinkedList<Foo>>; where the unbounded E is MyLinkedList<Foo> in the outer parameterized type and the unbounded E is Foo in the inner parameterized type.

In this working demonstration I've implemented a simplified representative model of a linked list. In my simplified model,Bar does not implement Comparable. MyLinkedList<E> itself does implement Comparable<E> though.

A usage example&hellip;

public class Bar { 

    private int y;

    public Bar(int y){ 
        this.y = y;
    }				
}
...
MyLinkedList<Bar> list1 = new MyLinkedList<>();
MyLinkedList<MyLinkedList<Bar>> list2 = new MyLinkedList<>();
MyLinkedList<Bar> list3 = new MyLinkedList<>();
...
list1.add(new Bar(100));
list2.add(list3);  
list3.add(new Bar(101));
...
if (list2.compareTo(list1) != 0){ ... }
...

Click the green Start button at the top of the demo. Then you can observe that it doesn't matter that E has no bounds in the declaration of MyLinkedList<E>. It does not matter that Bar does not implement Comparable.

It is absolutely possible to compare two Comparable parameterized instantiations of MyLinkedList<E> with no problem&hellip;

...
[node -> [node -> Bar: y=101]] is greater than [node -> Bar: y=100]
...

It's worth repeating: In my demonstration model, Bar does not implement Comparable.

It's worth pointing out too that regardless of type erasure, what's observed in stdout shows that whatever the runtime type of the node displayed here is, it has all the public, non-static members of type Bar.