Marc Dzaebel schreef:
> Hi there,
>
> l1,l2 are of type "long" and I need to compare them. Currently I do it by
>
> new Long(l1).compareTo(l2) // autoboxing
You could always use a LongComparator implements Comparator<Long, Long>
to avoid the new Long()
> However, there should be a static method in Long.compareTo(long l1, long l2)
> in order to avoid the generation of two unnecessary Long objects? The same
[quoted text clipped - 8 lines]
> something? May be the costs of creating the two objects (and collect them)
> are not as high as I assume?
Do you rely on the result of compareTo being -1 or +1? You shouldn’t!
If not, then why even write a function and not just use l1-l2?
Same goes for ints. For bytes, shorts and chars the situation is
different, because of auto-conversion. But then again, compareTo gives
you an int too, so this is exactly what you want.
Only for floating point numbers would you have to watch out, because
float1-float2 is not always 0, even when they have the ‘same’ value (or
the inverse).
H.
- --
Hendrik Maryns
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
Chris Uppal - 01 Jun 2006 14:42 GMT
> If not, then why even write a function and not just use l1-l2?
That's not safe if the arithmetic can wrap around.
-- chris
Patricia Shanahan - 01 Jun 2006 14:47 GMT
> Do you rely on the result of compareTo being -1 or +1? You
> shouldn’t! If not, then why even write a function and not just use
> l1-l2?
42L is greater than Long.MIN_VALUE, but 42L - Long.MIN_VALUE is
negative. The problem is that the subtraction result is greater than the
maximum value that can be stored in a long, and wraps around to a
negative number.
> Same goes for ints. For bytes, shorts and chars the situation is
> different, because of auto-conversion. But then again, compareTo
> gives you an int too, so this is exactly what you want.
The auto-conversion really helps here, because no pair of bytes, chars,
or shorts can have a difference greater than Integer.MAX_VALUE.
Patricia
Wibble - 02 Jun 2006 12:18 GMT
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
[quoted text clipped - 48 lines]
> =zXWI
> -----END PGP SIGNATURE-----
Autoboxing will work great in 1.5, but what about 1.4?
Arrays.sort requires objects passed to the comparator
and if you're sorting in a non-conventional order,
like by bits-set-count, then you're mostly out of luck.
> l1,l2 are of type "long" and I need to compare them. Currently I do it by
>
> new Long(l1).compareTo(l2) // autoboxing
There are only a few cases when you need an explicit method to compare
numbers. Typically simple if() statements are OK:
if(l1 > l2) {
} else if(l1 < l2) {
} else {
}
Which is anyhow simpler than:
int c = MyUtility.compareTo(l1, l2);
if(c > 0) {
} else if(c < 0) {
} else {
}
or
int c = new Long(l1).compareTo(l2);
if(c > 0) {
} else if(c < 0) {
} else {
}
You only need to explicitly call compareTo() methods in Java if you need
to determine some order between instances of a class, but if your code
has no knowledge about that order. This is typically not the case if you
know you are dealing with longs.
It is e.g. the case for universal/reusable sort routines which are
supposed to be capable of sorting "everything". Such routines are
typically written to handle only objects, not to handle primitive types
- to avoid having to duplicate code. So using such routines typically
has to result in boxing/unboxing when you want to use them with
primitives. But that boxing happens because of the particular sorting
routine's implementation. Methods like Long.compareTo() simply exist to
support such routines. They are not intended for general usage.
> However, there should be a static method in Long.compareTo(long l1, long l2)
> in order to avoid the generation of two unnecessary Long objects? The same
> problem occurrs for other primitive types. I would always have to write a
> methods like:
> public static int compareTo(long l1, long l2) {
> return l1<l2? -1 : l1==l2? 0 : 1;
> }
public static long compareTo(long l1, long l2) {
return l1 - l2;
}
> Shouldn't the current design
Design of what? What is it what you actually want to change? class Long?
/Thomas

Signature
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/
Hendrik Maryns - 01 Jun 2006 15:13 GMT
Thomas Weidenfeller schreef:
>> public static int compareTo(long l1, long l2) {
>> return l1<l2? -1 : l1==l2? 0 : 1;
[quoted text clipped - 3 lines]
> return l1 - l2;
> }
You stepped in the same trap as I did: this isn’t overflow-safe.
H.
- --
Hendrik Maryns
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
> However, there should be a static method in Long.compareTo(long l1, long
> l2) [...]
> Shouldn't the current design be refactored in this way or do I miss
> something?
I think it's just that there isn't a lot of need for such a method, and it's
easy enough to create your own. Maybe it'll be added someday.
-- chris
Marc Dzaebel - 01 Jun 2006 19:57 GMT
>> However, there should be a static method in Long.compareTo(long l1, long
>> l2) [...]
[quoted text clipped - 3 lines]
> it's
> easy enough to create your own. Maybe it'll be added someday.
Yes, maybe the tradeoff between language complexity and usefullness might be
the reason.
Thanks all for your comments!