Integer / Long comparison

Discussion in 'Java' started by grz01, Sep 9, 2009.

  1. grz01

    grz01 Guest

    Hi
    In JUnit I want to compare an Integer with a Long, as 2 Integers --
    say like this:

    Integer i = ...;
    Long l = ...;
    assertEquals(i,l); // assertEquals is ambigous, doesnt work

    Now, if I try this instead:

    Integer i = ...;
    Long l = ...;
    assertEquals(i,l.intValue);

    assertEquals() still complains it doesnt know whether I mean
    assertEquals(int, int) or
    assertEquals(Integer, Integer)

    Thus, if I write

    Integer i = ...;
    Long l = ...;
    assertEquals(i,(Integer)l.intValue);

    it does what I want, but seems a bit verbose with two "casts".

    So just wondered, Is there a direct way to go from Long to Integer,
    without the intermediate int-step ?

    / grz01
    grz01, Sep 9, 2009
    #1
    1. Advertising

  2. grz01

    Daniel Pitts Guest

    grz01 wrote:
    > Hi
    > In JUnit I want to compare an Integer with a Long, as 2 Integers --
    > say like this:
    >
    > Integer i = ...;
    > Long l = ...;
    > assertEquals(i,l); // assertEquals is ambigous, doesnt work

    This will always fail anyway, because they are different classes.
    >
    > Now, if I try this instead:
    >
    > Integer i = ...;
    > Long l = ...;
    > assertEquals(i,l.intValue);

    there is no such field called intValue.
    >
    > assertEquals() still complains it doesnt know whether I mean
    > assertEquals(int, int) or
    > assertEquals(Integer, Integer)

    Assuming you mean't intValue() above.
    >
    > Thus, if I write
    >
    > Integer i = ...;
    > Long l = ...;
    > assertEquals(i,(Integer)l.intValue);
    >
    > it does what I want, but seems a bit verbose with two "casts".

    intValue() isn't a cast. Either way, you're better off casting the i to
    a long (because there are longs that can't be represented as an integer,
    and your equals case might miss that)
    >
    > So just wondered, Is there a direct way to go from Long to Integer,
    > without the intermediate int-step ?

    If possible, use int and long to start with, rather than Integer and Long.

    Then you can do
    assertEquals((long)i, l);
    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, Sep 9, 2009
    #2
    1. Advertising

  3. grz01

    Lew Guest

    On Sep 9, 1:04 pm, Daniel Pitts
    <> wrote:
    > grz01 wrote:
    > > Hi
    > > In JUnit I want to compare an Integer with a Long, as 2 Integers --
    > > say like this:

    >
    > >   Integer i = ...;
    > >   Long l = ...;
    > >   assertEquals(i,l);     // assertEquals is ambigous, doesnt work

    >
    > This will always fail anyway, because they are different classes.
    >
    > > Now, if I try this instead:

    >
    > >   Integer i = ...;
    > >   Long l = ...;
    > >   assertEquals(i,l.intValue);

    >
    > there is no such field called intValue.
    >
    > > assertEquals() still complains it doesnt know whether I mean
    > > assertEquals(int, int) or
    > > assertEquals(Integer, Integer)

    >
    > Assuming you mean't intValue() above.
    >
    > > Thus, if I write

    >
    > >   Integer i = ...;
    > >   Long l = ...;
    > >   assertEquals(i,(Integer)l.intValue);

    >
    > > it does what I want, but seems a bit verbose with two "casts".

    >
    > intValue() isn't a cast.  Either way, you're better off casting the i to
    > a long (because there are longs that can't be represented as an integer,
    > and your equals case might miss that)
    >
    > > So just wondered, Is there a direct way to go from Long to Integer,
    > > without the intermediate int-step ?

    >
    > If possible, use int and long to start with, rather than Integer and Long..
    >
    > Then you can do
    > assertEquals((long)i, l);


    or

    assertEquals( i.longValue(), l.longValue() );


    Why make things complicated?

    --
    Lew
    Lew, Sep 9, 2009
    #3
  4. grz01

    grz01 Guest

    Hi Daniel,

    Yes, of course, I meant the intValue() method.

    This was a simplified example I wrote only to demonstrate the problem,
    but in the actual code I have here, the objects and types come from
    third-party frameworks we are using, so I cant use your advice re. int/
    long, etc.
    The Integer and Long types are what they are and cannot be changed.

    In my code it's actually something like

    assertEquals(good.grief(), (Integer)oh.dear().intValue())

    which doesnt look very nice...

    So, I am still interested if somebody can rewrite that line of code in
    a nicer way, without the casting/conversion in two separate steps.

    Instead of: Long -> int -> Integer,
    I was hoping you could do it in one direct step: Long -> Integer.

    Anyone?

    / grz01
    grz01, Sep 9, 2009
    #4
  5. grz01

    grz01 Guest

    >   assertEquals( i.longValue(), l.longValue() );
    >
    > Why make things complicated?
    >
    > --
    > Lew



    Thanks Lew, but still 2 different conversions in the code :)

    I would like only one, if possible :)
    grz01, Sep 9, 2009
    #5
  6. grz01

    Lew Guest

    grz01 wrote:
    > So, I am still interested if somebody can rewrite that line of code in
    > a nicer way, without the casting/conversion in two separate steps.
    >
    > Instead of:  Long -> int -> Integer,
    > I was hoping you could do it in one direct step: Long -> Integer.
    >


    Sometimes when working with classes like Long and Integer, a visit to
    their respective Javadocs might find methods in both that could make
    them commensurate, like, oh, say, longValue().

    The Javadocs are a very potent resource.

    --
    Lew
    Lew, Sep 9, 2009
    #6
  7. grz01

    Lew Guest

    Lew wrote:
    >>   assertEquals( i.longValue(), l.longValue() );

    >
    >> Why make things complicated?

    >

    grz01 <> wrote:
    > Thanks Lew, but still 2 different conversions in the code :)
    >
    > I would like only one, if possible :)


    ???

    What do you imagine the difficulty to be with the two "conversions"
    that you imagine happening here?

    --
    Lew
    Lew, Sep 9, 2009
    #7
  8. grz01

    grz01 Guest

    > What do you imagine the difficulty to be with the two "conversions"
    > that you imagine happening here?
    >
    > --
    > Lew



    Hi Lew,

    Just like with

    assertEquals(good.grief(), (Integer)oh.dear().intValue())

    it's not a "difficulty", admittedly. That works, too.
    I just think it would be neater with a single step, esp. when this
    type of code repeats many hundred times in our test-cases.

    But if someone can tell me, with certainty "NO, IT'S NOT POSSIBLE IN
    JAVA!"
    (to convert Long -> Integer in one step)
    then I would be fine with that answer, too :)
    and stop looking... :)

    / grz01
    grz01, Sep 9, 2009
    #8
  9. grz01

    Lew Guest

    Lew wrote:
    >>   assertEquals( i.longValue(), l.longValue() );

    >
    >> Why make things complicated?

    >


    grz01 wrote:
    > Thanks Lew, but still 2 different conversions in the code :)
    >
    > I would like only one, if possible :)
    >


    One of your "conversions" is the call to Long#longValue(), which does
    no conversion whatsoever. It extracts the underlying long value of
    the Long, something that equals() does anyway, so there's no escaping
    it. No additional cost there. The other "conversion" is actually two
    operations: the inescapable extraction of the underlying Integer int
    value, and the widening conversion to long. So that's two
    extractions, one widening conversion and a comparison with my
    suggestion.

    What you want is to convert, say, an Integer to a Long, not actually
    possible, followed by two extractions and a comparison. Even if
    conversion of Integer to Long were possible, no doubt it would be more
    expensive than the widening of an int to long.

    So do you prefer two extractions, an impossible class conversion and a
    comparison as you ask, or two extractions, a simple widening primitive
    conversion and a comparison, as I suggest?

    --
    Lew
    Lew, Sep 9, 2009
    #9
  10. grz01

    Lew Guest

    grz01 wrote:
    > But if someone can tell me, with certainty "NO, IT'S NOT POSSIBLE IN
    > JAVA!"
    > (to convert Long -> Integer in one step)
    > then I would be fine with that answer, too :)
    > and stop looking... :)


    The Javadocs tell you that, and that's the most authoritative
    "someone" there is for this question.

    Read the Javadocs.

    The Javadocs are a potent resource.

    Don't ignore the Javadocs.

    The answer to that question is yes, the conversion of Long to Integer,
    which, BTW, is the wrong direction to convert as you've already been
    told, as you can tell by reading the Javadocs.

    So I suggest that you read the Javadocs.

    --
    Lew
    Lew, Sep 9, 2009
    #10
  11. grz01

    Lew Guest

    Correction:

    Lew wrote:
    > The answer to that question is yes, the conversion of Long to Integer,
    > which, BTW, is the wrong direction to convert as you've already been
    > told,

    is impossible,
    > as you can tell by reading the Javadocs.


    --
    Lew
    Lew, Sep 9, 2009
    #11
  12. grz01 wrote:
    >> What do you imagine the difficulty to be with the two "conversions"
    >> that you imagine happening here?
    >>
    >> --
    >> Lew

    >
    >
    > Hi Lew,
    >
    > Just like with
    >
    > assertEquals(good.grief(), (Integer)oh.dear().intValue())
    >
    > it's not a "difficulty", admittedly. That works, too.
    > I just think it would be neater with a single step, esp. when this
    > type of code repeats many hundred times in our test-cases.



    Then write a method

    void assertEquals(String s, Long l, Integer i)
    {
    assertEquals(s, l.longValue(), i.longValue());
    }

    And call it as often as you like.
    Mike Schilling, Sep 9, 2009
    #12
  13. grz01

    Roedy Green Guest

    On Wed, 9 Sep 2009 09:28:31 -0700 (PDT), grz01 <> wrote,
    quoted or indirectly quoted someone who said :

    >
    >So just wondered, Is there a direct way to go from Long to Integer,


    see http://mindprod.com/applet/converter.html
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "The coolest thing to do with your data will be thought of by someone else."
    ~ Rufus Pollock (born: 1978 age: 31) in Talk.
    Roedy Green, Sep 9, 2009
    #13
  14. grz01

    Arne Vajhøj Guest

    grz01 wrote:
    >> What do you imagine the difficulty to be with the two "conversions"
    >> that you imagine happening here?

    > Just like with
    >
    > assertEquals(good.grief(), (Integer)oh.dear().intValue())
    >
    > it's not a "difficulty", admittedly. That works, too.
    > I just think it would be neater with a single step, esp. when this
    > type of code repeats many hundred times in our test-cases.


    Let us say that:
    - each instance adds 10 nano seconds to your test run
    - your test contains 1000 instances
    - your test is run 10000 times
    then it "cost" you a total of 1/10th of a second.

    Not worth it.

    Arne
    Arne Vajhøj, Sep 9, 2009
    #14
  15. grz01

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Sep 9, 2009
    #15
  16. 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.
    Mike Schilling, Sep 10, 2009
    #16
  17. grz01

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Sep 10, 2009
    #17
  18. 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
    Joshua Cranmer, Sep 10, 2009
    #18
  19. 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 .
    Mike Schilling, Sep 10, 2009
    #19
  20. Patricia Shanahan wrote:

    >
    > There is a simple approach to assertEquals that always works,
    > without
    > having to spend time rereading the method selection rules in the
    > JLS.
    >
    > Decide the appropriate type for the comparison. Cast/box/unbox etc.
    > to
    > force both the expect and actual arguments to be expressions of that
    > type. In the OP's case, I think the appropriate type for the
    > comparison is long, so I would use the longValue methods to get a
    > long from each of i and l.


    Unless null is a possible and perhaps expected result. Then it's a
    bit more complicated.
    Mike Schilling, Sep 11, 2009
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dan Pop
    Replies:
    0
    Views:
    1,168
    Dan Pop
    Jun 24, 2003
  2. cyberdude
    Replies:
    2
    Views:
    5,104
    Keith Thompson
    Jun 25, 2003
  3. music4
    Replies:
    3
    Views:
    896
    CBFalconer
    Jan 5, 2004
  4. Replies:
    7
    Views:
    928
    Maxim Yegorushkin
    Jun 15, 2006
  5. Suresh V
    Replies:
    5
    Views:
    3,677
    SaticCaster
    Jul 5, 2010
Loading...

Share This Page