unchecked call to compareTo(T)

M

Mark

hi,

I was just wondering how I might get rid of this error.. can't seem to
figure it out.

the error:

warning: [unchecked] unchecked call to compareTo(T) as a member of the
raw type java.lang.Comparable
else if( o.compareTo(n.o) < 0 )
^

the function:

private void insert(Comparable o, Node n)
{
if( n == null )
n = new Node(o);
else if( o.compareTo(n.o) < 0 )
insert(o,n.l);
else
insert(o,n.r);
}

my node class:

class Node
{
public Object o = null;
public Node l = null;
public Node r = null;

Node(Object obj) {
o = obj;
}
}


thanks guys.
 
M

Mark

Mark said:
hi,

I was just wondering how I might get rid of this error.. can't seem to
figure it out.

the error:

warning: [unchecked] unchecked call to compareTo(T) as a member of the
raw type java.lang.Comparable
else if( o.compareTo(n.o) < 0 )
^

the function:

private void insert(Comparable o, Node n)
{
if( n == null )
n = new Node(o);
else if( o.compareTo(n.o) < 0 )
insert(o,n.l);
else
insert(o,n.r);
}

my node class:

class Node
{
public Object o = null;
public Node l = null;
public Node r = null;

Node(Object obj) {
o = obj;
}
}


thanks guys.
Click to expand...

i'm serious.. I need help.

I cant do something like Comparable<Object> because then it only takes
objects..whereas I want I want it to accept anything that implements
Comparable.
 
P

Piotr Kobzda

Mark wrote:

[...]
I cant do something like Comparable<Object> because then it only takes
objects..whereas I want I want it to accept anything that implements
Comparable.
Click to expand...

How would accepting anything that implements Comparable be useful for you?

Having for example:

Comparable c1 = "";
Comparable c2 = 1;

both c1.compareTo(c2) and c2.compareTo(c1) will end in runtime exception.

You just can not simply compare things which are not comparable to each
other, even when they are all comparable to something (usually to
compatible type objects only).


The solution would be (and I suppose it's the best approach in your
case) applying more knowledge on data type held by Nodes. You can
achieve that by parameterizing both your code and Node class and than
use Node<T> and Comparable<T> (or somewhat like Comparable<? super T>)
instead.

You can also solve it using Comparator<Object> which will be able to
compare two distinct type objects applying your specific comparison
rules in compare() method. Unfortunately, this will most probably end
in _very awful_, not OO, implementation of compare(), similar to the
following one:

public int compare(Object o1, Object o2) {
if (o1 instanceof String)
return ((String)o1).compareTo((String)o2);
if (o1 instanceof Integer)
return ((Integer)o1).compareTo((Integer)o2);
...


So I presume you'll need to rethink a little your design again.


piotr
 
M

Mark

Piotr said:
Mark wrote:

[...]
I cant do something like Comparable<Object> because then it only takes
objects..whereas I want I want it to accept anything that implements
Comparable.
Click to expand...

How would accepting anything that implements Comparable be useful for you?

Having for example:

Comparable c1 = "";
Comparable c2 = 1;

both c1.compareTo(c2) and c2.compareTo(c1) will end in runtime exception.

You just can not simply compare things which are not comparable to each
other, even when they are all comparable to something (usually to
compatible type objects only).


The solution would be (and I suppose it's the best approach in your
case) applying more knowledge on data type held by Nodes. You can
achieve that by parameterizing both your code and Node class and than
use Node<T> and Comparable<T> (or somewhat like Comparable<? super T>)
instead.

You can also solve it using Comparator<Object> which will be able to
compare two distinct type objects applying your specific comparison
rules in compare() method. Unfortunately, this will most probably end
in _very awful_, not OO, implementation of compare(), similar to the
following one:

public int compare(Object o1, Object o2) {
if (o1 instanceof String)
return ((String)o1).compareTo((String)o2);
if (o1 instanceof Integer)
return ((Integer)o1).compareTo((Integer)o2);
...


So I presume you'll need to rethink a little your design again.


piotr
Click to expand...

Well, I guess I should have said that the objects can be of any type,
as long as they are of the same type. Which I guess means I need to
make the Node generic as well... and thus my entire BinaryTree class
generic. I haven't really dealt with generics in Java yet..so, it's
all new to me.
 
M

Mark

Thomas said:
Really? I am sure we all thought it was just a joke.

http://moinmoin.riters.com/JINX/index.cgi/Suggestions_20for_20Asking_20Questions_20on_20Newsgroups
http://moinmoin.riters.com/JINX/ind...20Asking_20Questions_20on_20Newsgroups#Urgent
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html

/Thomas
Click to expand...

Sorry, I guess I got a little impatient. I skimmed through the article
and bookmarked it.
I tried using generics, but was unsuccessful. Perhaps I don't fully
understand them yet, but I just wanted a quick fix for now.
 
M

Mark

Piotr said:
The solution would be (and I suppose it's the best approach in your
case) applying more knowledge on data type held by Nodes. You can
achieve that by parameterizing both your code and Node class and than
use Node<T> and Comparable<T> (or somewhat like Comparable<? super T>)
instead.
Click to expand...

So, I tried this...

class BST<T extends Comparable>
{
class Node<T>
{
T obj = null;
Node left = null, right = null;

Node(T obj) {
this.obj = obj;
}
}

Node root = null;
int nElements = 0;

public void insert(T obj)
{
root = insert(obj,root);
++nElements;
}

private Node insert(T obj, Node node)
{
if( node == null )
node = new Node(obj);
else if( obj.compareTo(node.obj) < 0 )
node.left = insert(obj,node.left);
else
node.right = insert(obj,node.right);
return node;
}

}

But I get the same warnings. If both obj and node.obj are of the same
type, why is it complaining? Adding more <T>'s just adds more
warnings... I'm not really sure how this works. What is the proper
syntax?
 
M

Mark

I seem to have solved the problem, but I really have no idea what I
did. Could someone explain what the <? super T> part means?

(code below if interested)

class BST<T extends Comparable<? super T>>
{
class Node
{
T obj = null;
Node left = null, right = null;

Node(T obj) {
this.obj = obj;
}
}

Node root = null;
int nElements = 0;
int index = 0;

public void insert(T obj)
{
root = insert(obj,root);
++nElements;
}

private Node insert(T obj, Node node)
{
if( node == null )
node = new Node(obj);
else if( obj.compareTo(node.obj) < 0 )
node.left = insert(obj,node.left);
else
node.right = insert(obj,node.right);
return node;
}

...
 
M

Mark

Writing it as follows seems to fix the problem

class BST<T extends Comparable<? super T>>
{
class Node
{
T obj = null;
Node left = null, right = null;

Node(T obj) {
this.obj = obj;
}
}
...

But now I'm having trouble declaring a new BST. I get the errors...

BST.java:196: unexpected type
found : int
required: reference
BST<int> tree = new BST<int>();
^
BST.java:196: unexpected type
found : int
required: reference
BST<int> tree = new BST<int>();
^
2 errors
Terminated with exit code 1.
Click to expand...

I'm not sure what it means...it expects a reference? Why won't it
accept "int"?

*quick test*

It seems to accept Integer though...why is that?
 
H

Hendrik Maryns

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark schreef:
Writing it as follows seems to fix the problem

class BST<T extends Comparable<? super T>>
{
class Node
{
T obj = null;
Node left = null, right = null;

Node(T obj) {
this.obj = obj;
}
}
...

But now I'm having trouble declaring a new BST. I get the errors...

BST.java:196: unexpected type
found : int
required: reference
BST<int> tree = new BST<int>();
^
BST.java:196: unexpected type
found : int
required: reference
BST<int> tree = new BST<int>();
^
2 errors


I'm not sure what it means...it expects a reference? Why won't it
accept "int"?
Click to expand...

int is a primitive type, it does not implement anything, so most
certainly not Comparable. The moment you generified BST, you demanded
its objects to implement Comparable. Anyway, there is not way to store
an int in a collection, so you want to use Integer anyway.
It seems to accept Integer though...why is that?
Click to expand...

Because Integer implements Comparable<Integer>.

To answer your other post:
Could someone explain what the <? super T> part means?
Click to expand...

Comparable itself is generic. This means you have to give it a
parameter, hence the errors didn’t disappear at your first try, since
you just declared BST<T extends Comparable>.

Now why the super T? Often, a class SuperClass will declare it
implements Comparable. Most often, it will be comparable with itself,
so it will implement Comparable<SuperClass>. (E.g. look at the
definition of Integer.) However, if subclasses of this class are made,
they, too, implement Comparable<SuperClass>. You cannot redefine them
to implement Comparable<SubClass>, the compiler won’t let you. But you
do want to accept these classes in BST. That’s where the super comes
in: it tells the compiler that a class should be comparable to itself or
to some class higher up in the hierarchy.

HTH,H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFFSy7He+7xMGD3itQRArz5AJ9S1vn1CS7pJTlqg2HhxsiX5KD+DQCfVUto
Xj1WAw3Lc6a3AXX8ycTqNwM=
=CDaC
-----END PGP SIGNATURE-----
 
M

Mark

Hendrik said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark schreef:

int is a primitive type, it does not implement anything, so most
certainly not Comparable. The moment you generified BST, you demanded
its objects to implement Comparable. Anyway, there is not way to store
an int in a collection, so you want to use Integer anyway.


Because Integer implements Comparable<Integer>.

To answer your other post:


Comparable itself is generic. This means you have to give it a
parameter, hence the errors didn't disappear at your first try, since
you just declared BST<T extends Comparable>.

Now why the super T? Often, a class SuperClass will declare it
implements Comparable. Most often, it will be comparable with itself,
so it will implement Comparable<SuperClass>. (E.g. look at the
definition of Integer.) However, if subclasses of this class are made,
they, too, implement Comparable<SuperClass>. You cannot redefine them
to implement Comparable<SubClass>, the compiler won't let you. But you
do want to accept these classes in BST. That's where the super comes
in: it tells the compiler that a class should be comparable to itself or
to some class higher up in the hierarchy.

HTH,H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFFSy7He+7xMGD3itQRArz5AJ9S1vn1CS7pJTlqg2HhxsiX5KD+DQCfVUto
Xj1WAw3Lc6a3AXX8ycTqNwM=
=CDaC
-----END PGP SIGNATURE-----
Click to expand...

ah... thank you.

I found the integer definition, it says

public final class Integer
extends Number
implements Comparable

not Comparable<Integer>, .. actually.. I guess those doc's are outdated
now (1.4.2)
generics were introduced in 1.5 or something, weren't they?

anyways, that makes much more sense now.

the broad statement "everything is derived from Object" led me to
believe that even int's were.. and if they were derived from objects, I
figured they might implement Comparable as well, but I guess I was
wrong. (or are they still considered Objects?)
 
H

Hendrik Maryns

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark schreef:
Hendrik Maryns wrote:
Mark schreef:
int is a primitive type, it does not implement anything, so most
certainly not Comparable. The moment you generified BST, you demanded
its objects to implement Comparable. Anyway, there is not way to store
an int in a collection, so you want to use Integer anyway.

Because Integer implements Comparable<Integer>.

To answer your other post:

Comparable itself is generic. This means you have to give it a
parameter, hence the errors didn't disappear at your first try, since
you just declared BST<T extends Comparable>.

Now why the super T? Often, a class SuperClass will declare it
implements Comparable. Most often, it will be comparable with itself,
so it will implement Comparable<SuperClass>. (E.g. look at the
definition of Integer.) However, if subclasses of this class are made,
they, too, implement Comparable<SuperClass>. You cannot redefine them
to implement Comparable<SubClass>, the compiler won't let you. But you
do want to accept these classes in BST. That's where the super comes
in: it tells the compiler that a class should be comparable to itself or
to some class higher up in the hierarchy.

HTH,H.
Click to expand...
ah... thank you.
Click to expand...
I found the integer definition, it says
Click to expand...
public final class Integer
extends Number
implements Comparable
Click to expand...
not Comparable<Integer>, .. actually.. I guess those doc's are outdated
now (1.4.2)
generics were introduced in 1.5 or something, weren't they?
Click to expand...

Indeed, you must be looking in the wrong place. If you have the Sun
JDK, then you have the source code too (search for src.zip), have a look
there.
anyways, that makes much more sense now.
Click to expand...
the broad statement "everything is derived from Object" led me to
believe that even int's were.. and if they were derived from objects, I
figured they might implement Comparable as well, but I guess I was
wrong. (or are they still considered Objects?)
Click to expand...

Nop, everything is derived from Object, except primitive types. Whether
this is a good design decision is another discussion... (E.g. in
Eiffel, even integers are objects.)

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFFUF45e+7xMGD3itQRAnllAJ9fjLxyP/mVuR50h7t5hYE4kKmPzACeKyZk
W92xD+A+FoZKOKB6zKOCRUw=
=kJKS
-----END PGP SIGNATURE-----
 
M

Mark

Hendrik said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark schreef:





Indeed, you must be looking in the wrong place. If you have the Sun
JDK, then you have the source code too (search for src.zip), have a look
there.



Nop, everything is derived from Object, except primitive types. Whether
this is a good design decision is another discussion... (E.g. in
Eiffel, even integers are objects.)

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFFUF45e+7xMGD3itQRAnllAJ9fjLxyP/mVuR50h7t5hYE4kKmPzACeKyZk
W92xD+A+FoZKOKB6zKOCRUw=
=kJKS
-----END PGP SIGNATURE-----
Click to expand...

haha... yes, better not get me stirred up about that :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

unchecked conversion warning. 32
Unchecked call to compareTo 14
pass-by-reference 14
Warning unchecked call 8
Need help with compareTo method 0
Infinite loop problem 1
unchecked casts and clone 5
Creating books with Sets 1

Members online

No members online now.
Total: 114 (members: 0, guests: 114)
Robots: 320

Forum statistics

Threads
473,767
Messages
2,569,571
Members
45,045
Latest member
DRCM

Latest Threads

Top