Prev: JDK 1.5.0_21 released
Next: LWUIT and J2ME
From: Arne Vajhøj on 9 Sep 2009 18:42
Patricia Shanahan wrote:
> Even if the value of a Long is supposed to be in the Integer range, a
> unit test should check that it is in range, not assume it.

Very relevant point.

It is not good to check if some code is OK by
assuming that the code is OK.

Arne
From: Mike Schilling on 9 Sep 2009 21:01
Arne Vajh�j wrote:
> Patricia Shanahan wrote:
>> Even if the value of a Long is supposed to be in the Integer range,
>> a
>> unit test should check that it is in range, not assume it.
>
> Very relevant point.
>
> It is not good to check if some code is OK by
> assuming that the code is OK.

I'm also wondering why Longs and Integers insread of longs and ints.
(assertEquals(long, int) would unambiguously call the (long, long)
overload).Without seeing the code it's hard to tell, but I wonder if
it should be using primitives, but autoboxing had made using objects
instead transparent until this cropped up.


From: Arne Vajhøj on 9 Sep 2009 21:38
Mike Schilling wrote:
> Arne Vajh�j wrote:
>> Patricia Shanahan wrote:
>>> Even if the value of a Long is supposed to be in the Integer range,
>>> a
>>> unit test should check that it is in range, not assume it.
>> Very relevant point.
>>
>> It is not good to check if some code is OK by
>> assuming that the code is OK.
>
> I'm also wondering why Longs and Integers insread of longs and ints.
> (assertEquals(long, int) would unambiguously call the (long, long)
> overload).Without seeing the code it's hard to tell, but I wonder if
> it should be using primitives, but autoboxing had made using objects
> instead transparent until this cropped up.

Maybe they need to be nullable.

But changing them to simple types would absolute help on the problem.

Arne
From: Joshua Cranmer on 9 Sep 2009 21:57
Mike Schilling wrote:
> I'm also wondering why Longs and Integers insread of longs and ints.
> (assertEquals(long, int) would unambiguously call the (long, long)
> overload).Without seeing the code it's hard to tell, but I wonder if
> it should be using primitives, but autoboxing had made using objects
> instead transparent until this cropped up.

A (Long, Integer) can be passed into a (long, long) method call, so it's
not necessarily the autounboxing per se that's causing the problem.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
From: Mike Schilling on 10 Sep 2009 03:32
Joshua Cranmer wrote:
> Mike Schilling wrote:
>> I'm also wondering why Longs and Integers insread of longs and
>> ints.
>> (assertEquals(long, int) would unambiguously call the (long, long)
>> overload).Without seeing the code it's hard to tell, but I wonder
>> if
>> it should be using primitives, but autoboxing had made using
>> objects
>> instead transparent until this cropped up.
>
> A (Long, Integer) can be passed into a (long, long) method call, so
> it's not necessarily the autounboxing per se that's causing the
> problem.

The problem, I suspect, is that assertEquals() has many, many
overloads, and the result is that which one to call is ambiguous .


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: JDK 1.5.0_21 released
Next: LWUIT and J2ME