FAQ

On 20/12/2007, at 8:44 PM, torehalset@apache.org wrote:

java 5: new Integer(int) -> Integer.valueOf(int)
Or we could start to use autoboxing and just use "int" where
appropriate. Is valueOf recommended over new Integer() for speed or
other reasons in Java 5?

Ari



-------------------------->
Aristedes Maniatis
phone +61 2 9660 9700
PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8

Search Discussions

  • Tore Halset at Dec 20, 2007 at 12:07 pm
    Hello.

    (sorry if this show up several times. looks like I have some unstable
    mail today..)
    On Dec 20, 2007, at 10:47 , Aristedes Maniatis wrote:
    On 20/12/2007, at 8:44 PM, torehalset@apache.org wrote:

    java 5: new Integer(int) -> Integer.valueOf(int)
    Or we could start to use autoboxing and just use "int" where
    appropriate. Is valueOf recommended over new Integer() for speed or
    other reasons in Java 5?

    I am currently -1 to autoboxing, but Integer.valueOf(int) should not
    be a problem for anyone.

    From javadoc:
    "Returns a Integer instance representing the specified int value. If a
    new Integer instance is not required, this method should generally be
    used in preference to the constructor Integer(int), as this method is
    likely to yield significantly better space and time performance by
    caching frequently requested values."

    http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Integer.html#valueOf(int)

    Regards,
    - Tore.
  • Kevin Menard at Dec 20, 2007 at 1:35 pm

    On 12/20/07 7:06 AM, "Tore Halset" wrote:


    I am currently -1 to autoboxing, but Integer.valueOf(int) should not
    be a problem for anyone.
    Why is that? I was just about to commit changes that replaces all of the
    explicit unboxing and boxing code with autoboxing. This would improve code
    clarity in various places.

    Autoboxing yields nearly identical bytecode to manual boxing/unboxing
    operations. The only time I've found it's problematic is when you forget
    what type you're working with to the point that you really should be using
    the object type or the primitive type natively.

    --
    Kevin
  • Tore Halset at Dec 20, 2007 at 2:48 pm

    On Dec 20, 2007, at 14:35 , Kevin Menard wrote:
    On 12/20/07 7:06 AM, "Tore Halset" wrote:


    I am currently -1 to autoboxing, but Integer.valueOf(int) should not
    be a problem for anyone.
    Why is that? I was just about to commit changes that replaces all
    of the
    explicit unboxing and boxing code with autoboxing. This would
    improve code
    clarity in various places.
    It will make the code smaller, but will the code be clearer? As in
    easier to understand?
    Autoboxing yields nearly identical bytecode to manual boxing/unboxing
    operations. The only time I've found it's problematic is when you
    forget
    what type you're working with to the point that you really should be
    using
    the object type or the primitive type natively.
    I have been bitten by a couple of situations where I thought my
    primitive type was primitive, but in fact had been autoboxed. This is
    extra confusing when you have objects that have identical methods, but
    with primitive and non primitive arguments. Like
    List<Integer>.remove(int) and List<Integer>.remove(Integer) doing two
    very different things. It is also a bit confusing when autoboxing
    happens when you do not know about it. I do not have that many good
    examples, but have googled some discussion around the subject.

    http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/867001348831/r/448008648831
    http://www.theserverside.com/news/thread.tss?thread_id=27129

    Perhaps I can learn to like it over time :) What about you other guys?

    - Tore.
  • Kevin Menard at Dec 20, 2007 at 3:08 pm

    On 12/20/07 9:48 AM, "Tore Halset" wrote:

    Why is that? I was just about to commit changes that replaces all
    of the
    explicit unboxing and boxing code with autoboxing. This would
    improve code
    clarity in various places.
    It will make the code smaller, but will the code be clearer? As in
    easier to understand?
    I certainly think so. "new Character(b)"; "x.intValue()"; etc. They all
    detract from the core logic. It'd really help the legibility of the ternary
    expressions, IMHO.

    I view boxing as a subclass of casting and think it's largely unnecessary.
    I have been bitten by a couple of situations where I thought my
    primitive type was primitive, but in fact had been autoboxed. This is
    extra confusing when you have objects that have identical methods, but
    with primitive and non primitive arguments. Like
    List<Integer>.remove(int) and List<Integer>.remove(Integer) doing two
    very different things. It is also a bit confusing when autoboxing
    happens when you do not know about it. I do not have that many good
    examples, but have googled some discussion around the subject.
    Right, but then the question is are you really using the proper type in the
    first place? Calling intValue() may make things more explicit, but if
    you're doing it enough where autoboxing is a problem, maybe you should be
    using a primitive type to begin with.
    I can get over it, but I think we employ other practices that can lead to
    more serious bugs. Complex ternary expressions, assignment to method
    parameters, assignment to catch block parameters, use of nested postfix
    operators, etc. But that's drawn from my own experience as well.

    Let me start using "final" and I'll give up on autoboxing ;-)

    --
    Kevin
  • Andrus Adamchik at Dec 20, 2007 at 3:17 pm
    I agree with Tore... Autoboxing is a confusing solution for the legacy
    design holes in Java. It mostly obfuscates things. Having said that, I
    guess since it is an official language feature now, we should not
    prohibit its use in the Cayenne codebase. But making a special effort
    to use it throughout the code looks like a waste of time.

    Andrus

    On Dec 20, 2007, at 4:48 PM, Tore Halset wrote:
    On Dec 20, 2007, at 14:35 , Kevin Menard wrote:
    On 12/20/07 7:06 AM, "Tore Halset" wrote:


    I am currently -1 to autoboxing, but Integer.valueOf(int) should not
    be a problem for anyone.
    Why is that? I was just about to commit changes that replaces all
    of the
    explicit unboxing and boxing code with autoboxing. This would
    improve code
    clarity in various places.
    It will make the code smaller, but will the code be clearer? As in
    easier to understand?
    Autoboxing yields nearly identical bytecode to manual boxing/unboxing
    operations. The only time I've found it's problematic is when you
    forget
    what type you're working with to the point that you really should
    be using
    the object type or the primitive type natively.
    I have been bitten by a couple of situations where I thought my
    primitive type was primitive, but in fact had been autoboxed. This
    is extra confusing when you have objects that have identical
    methods, but with primitive and non primitive arguments. Like
    List<Integer>.remove(int) and List<Integer>.remove(Integer) doing
    two very different things. It is also a bit confusing when
    autoboxing happens when you do not know about it. I do not have that
    many good examples, but have googled some discussion around the
    subject.

    http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/867001348831/r/448008648831
    http://www.theserverside.com/news/thread.tss?thread_id=27129

    Perhaps I can learn to like it over time :) What about you other guys?

    - Tore.
  • Kevin Menard at Dec 20, 2007 at 3:21 pm

    On 12/20/07 10:17 AM, "Andrus Adamchik" wrote:

    I agree with Tore... Autoboxing is a confusing solution for the legacy
    design holes in Java. It mostly obfuscates things. Having said that, I
    guess since it is an official language feature now, we should not
    prohibit its use in the Cayenne codebase. But making a special effort
    to use it throughout the code looks like a waste of time.
    If that's how you guys feel, I'm not going to push the issue. I do just
    want to note that with IDEA I can change the whole codebase in 10 min.
    though. The inspections are quite good.

    --
    Kevin
  • Aristedes Maniatis at Dec 20, 2007 at 9:49 pm

    On 21/12/2007, at 1:48 AM, Tore Halset wrote:

    I have been bitten by a couple of situations where I thought my
    primitive type was primitive, but in fact had been autoboxed. This
    is extra confusing when you have objects that have identical
    methods, but with primitive and non primitive arguments. Like
    List<Integer>.remove(int) and List<Integer>.remove(Integer) doing
    two very different things. It is also a bit confusing when
    autoboxing happens when you do not know about it. I do not have that
    many good examples, but have googled some discussion around the
    subject.

    http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/867001348831/r/448008648831
    http://www.theserverside.com/news/thread.tss?
    I agree that it can be confusing in some cases, but it isn't like we
    can just switch it off. The places where it is confusing is where it
    happens without you realising it is happening. The places where it
    makes the code easier to read (IMO) are when you use it intentionally
    and might look like this:

    static public Integer SOME_CONSTANT = 5;

    But really, I think it a pretty minor issue. I wasn't aware of the
    speed enhancement of Integer.valueOf(int) and that is pretty nice as
    long as we are sure those particular Integers are immutable.

    Ari


    -------------------------->
    ish
    http://www.ish.com.au
    Level 1, 30 Wilson Street Newtown 2042 Australia
    phone +61 2 9550 5001 fax +61 2 9550 4001
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
  • Tore Halset at Dec 21, 2007 at 7:04 am

    On Dec 20, 2007, at 22:49 , Aristedes Maniatis wrote:

    I agree that it can be confusing in some cases, but it isn't like we
    can just switch it off. The places where it is confusing is where it
    happens without you realising it is happening.
    Thanks, I have realized that now. It is not possible to get it turned
    off by not using it as it can pop up everywhere. So I rest my "-1" and
    are now a "+0" on this issue :)
    The places where it makes the code easier to read (IMO) are when you
    use it intentionally and might look like this:

    static public Integer SOME_CONSTANT = 5;

    But really, I think it a pretty minor issue.
    Not that big win for me with a big monitor :)
    I wasn't aware of the speed enhancement of Integer.valueOf(int) and
    that is pretty nice as long as we are sure those particular Integers
    are immutable.

    Integer is immutable. Autoboxing of ints probably uses
    Integer.valueOf(int).

    - Tore.
  • Kevin Menard at Dec 21, 2007 at 2:50 pm

    On 12/21/07 2:03 AM, "Tore Halset" wrote:
    On Dec 20, 2007, at 22:49 , Aristedes Maniatis wrote:

    I agree that it can be confusing in some cases, but it isn't like we
    can just switch it off. The places where it is confusing is where it
    happens without you realising it is happening.
    Thanks, I have realized that now. It is not possible to get it turned
    off by not using it as it can pop up everywhere. So I rest my "-1" and
    are now a "+0" on this issue :)
    There's actually an inspection in IDEA that will detect autoboxing so you
    can undo it. Granted, Eclipse is the development tool of choice for the
    project, but I find it nice to float between the two. In any event, if it
    were a big problem, I could periodically scan the code base and deal with.

    Sounds to me like it isn't all that necessary anyway, so this is more of an
    FYI.

    --
    Kevin
  • Craig L Russell at Dec 29, 2007 at 10:30 pm
    I didn't see a reply to this one.
    On Dec 20, 2007, at 1:47 AM, Aristedes Maniatis wrote:

    On 20/12/2007, at 8:44 PM, torehalset@apache.org wrote:

    java 5: new Integer(int) -> Integer.valueOf(int)
    Or we could start to use autoboxing and just use "int" where
    appropriate. Is valueOf recommended over new Integer() for speed or
    other reasons in Java 5?
    Yes, it's recommended. The valueOf method returns an instance that
    might already be lying around whereas new Integer will always create
    an object that will have to be garbage collected later. So valueOf is
    preferable if the code will always be run in a Java 5 or better vm.

    Craig
    Ari



    -------------------------->
    Aristedes Maniatis
    phone +61 2 9660 9700
    PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
    Craig Russell
    Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
    408 276-5638 mailto:Craig.Russell@sun.com
    P.S. A good JDO? O, Gasp!

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedDec 20, '07 at 9:48a
activeDec 29, '07 at 10:30p
posts11
users6
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase