• (cs)

    My guess is that 0 and 1 are special-cased FOR SPEED!!!

  • (cs)

    Why use auto [un]boxing and built in classes when you can write code to do it yourself?

  • Mook (unregistered) 
        public int compareTo(Object o)
    { return i.compareTo((Integer)o); }
    public int compareTo(Integer anotherInteger)
    { return i.compareTo(anotherInteger); }

    I love the ClassCastException waiting to happen in here. If comparing object is an Integer, then use that method, if it's any other object, well we'll damn well MAKE it an Integer anyway...and crash the program in the meantime.

  • Cristian (unregistered) in reply to snoofle
    snoofle:
    Why use auto [un]boxing and built in classes when you can write code to do it yourself?
    My guess is they wanted breakpoints in there! >:-)
  • The Doubtful Guest (unregistered)

    CommentUtils.getIntegerValueOf(int) makes perfect sense -- you avoid allocating an object when boxing commonly used int values. This will improve performance by giving the garbage collector less to do. (See also string interning).

    No WTF to see here, please move along.

  • Sleepyhead (unregistered)

    public class CommentType { Comment c;

    public static void Post()
{
    c.Post();
}

    }

    CommentType.Post();

  • (cs) in reply to Andy Goth
    Andy Goth:
    My guess is that 0 and 1 are special-cased FOR SPEED!!!

    Not for speed, for better memory management. I guess that they were somehow connected to a boolean value (0 for false and 1 for true). BTW I'd use -1 for FILE_NOT_FOUND

  • Philipp (unregistered)

    Ok, maybe, just maybe, and I am stretching here, there is a case where that code might make some sense... Have you ever tried to do this:

    Integer a = new Integer(11); Integer b = new Integer(11); System.out.println(a == b);

    (yes "=="; not equals). What do you guess will be the result? Depending on your VM implementation, this will most certainly yield --- true... Maybe the developers of the above code didn't want that and thus always compared something like new IntegerType instead...

    But really: Who cares? WTF...

  • Tom (unregistered) 
    getIntegerValueOf(int value)
    Kinda says it all right there, doesn't it?

    But maybe they do have something here. After all, you're not supposed to hardcode numbers throughout your files. So his manager probably told him to find all occurrences of '0' and replace it with 'DomainConstants.INTEGER_0'. Programmer remembers that whenever you find yourself pasting the same code over and over you should call a function to do it instead.

    So TRWTF is here:

    if ( value == 0 ) {
result = DomainConstants.INTEGER_0;
    should be:
    if ( value == DomainConstants.INTEGER_0 ) {
result = DomainConstants.INTEGER_0;

  • (cs) in reply to The Doubtful Guest
    The Doubtful Guest:
    CommentUtils.getIntegerValueOf(int) makes perfect sense -- you avoid allocating an object when boxing commonly used int values. This will improve performance by giving the garbage collector less to do.

    Correct, except that Integer.valueOf() already does this, only better (it has all ints between -128 and 127 precomputed). Though IIRC this is a relatively new feature, so CommonUtils.getIntegerValueOf() might make sense if you run on an older JRE and use specifically 0 and 1 a lot.

  • (cs) in reply to Mook
    Mook :
        public int compareTo(Object o)
    { return i.compareTo((Integer)o); }
    public int compareTo(Integer anotherInteger)
    { return i.compareTo(anotherInteger); }

    I love the ClassCastException waiting to happen in here. If comparing object is an Integer, then use that method, if it's any other object, well we'll damn well MAKE it an Integer anyway...and crash the program in the meantime.

    In particular, if comparing with an IntegerType...

  • (cs)

    I love how IntegerType has all the methods from the Number interface but does not actually implement it.

  • Anonymous (unregistered)

    Anyone who thinks that getIntegerValueOf is a useful construct (based on the increased performance) should really try some benchmarking first. Is it really worth reinventing the wheel for those few nanoseconds??? Sure, there may be merit in a very few critical scenarios but I bet this code was not applied to any such scenario.

  • stanbeard (unregistered) in reply to The Doubtful Guest

    Exactly! All instances of 1 and 0 point to the same static values. If you use a lot of 1s and 0s it seems like this would save a lot of memory.

  • tk (unregistered) in reply to SlyEcho
    SlyEcho:
    I love how IntegerType has all the methods from the Number interface but does not actually implement it.

    You must be using the prototype of Java 10... Last time I checked Number is an abstract class and not an interface in the versions used by the rest of the world.

  • Jon Skeet (unregistered) in reply to Philipp
    Philipp:
    Ok, maybe, just maybe, and I am stretching here, there is a case where that code might make some sense... Have you ever tried to do this:

    Integer a = new Integer(11); Integer b = new Integer(11); System.out.println(a == b);

    (yes "=="; not equals). What do you guess will be the result? Depending on your VM implementation, this will most certainly yield --- true... Maybe the developers of the above code didn't want that and thus always compared something like new IntegerType instead...

    But really: Who cares? WTF...

    How could it possibly return true? Note that that code isn't using autoboxing. If you'd written:

    Integer a = 11; Integer b = 11; System.out.println(a == b);

    then it might well return true... but without any actual autoboxing going on, I can't see it.

    Jon

  • Daniel (unregistered) in reply to The Doubtful Guest

    The WTF is that the Interger.class does this itself!

    Integer.valueOf(myInt) returns always the same object for all lower than n numbern (where n is 100 afaik).

  • vereor (unregistered) in reply to Philipp
    Philipp:
    Ok, maybe, just maybe, and I am stretching here, there is a case where that code might make some sense... Have you ever tried to do this:

    Integer a = new Integer(11); Integer b = new Integer(11); System.out.println(a == b);

    (yes "=="; not equals). What do you guess will be the result? Depending on your VM implementation, this will most certainly yield --- true... Maybe the developers of the above code didn't want that and thus always compared something like new IntegerType instead...

    But really: Who cares? WTF...

    NO IT WILL NOT. EVER. It will always be false. It will never depend on the VM. Never never never.

    You could mean either boxing or valueOf. Then the -128 to +128 (or something like that) will always be true, the rest will depend on the VM. But if you see "new" it will ALWAYS be a new object. Always.

  • Anonymous (unregistered) in reply to Anonymous

    I did something very similar several years ago - before Integer.valueOf came in Java 5. It was used while parsing XML files which where several MB in size. At that time main memory of PCs where usually <= 256 MV so it made a big difference in memory consumption for this parser. So there is really no WTF in this.

  • delenit (unregistered) in reply to stanbeard
    stanbeard:
    Exactly! All instances of 1 and 0 point to the same static values. If you use a lot of 1s and 0s it seems like this would save a lot of memory.
    Only if the 0 and 1's have a large scope.
  • Anonymous (unregistered) in reply to Tom
    Tom:
    So TRWTF is here:
    if ( value == 0 ) {
  result = DomainConstants.INTEGER_0;
    should be:
    if ( value == DomainConstants.INTEGER_0 ) {
  result = DomainConstants.INTEGER_0;

    Supposed that this code was used before auto(un)boxing came with Java 5 (becuase if it was used with Java 5 it would be really a WTF) - how should this even compile?

  • Baz (unregistered) in reply to Mook
    I love the ClassCastException waiting to happen in here. If comparing object is an Integer, then use that method, if it's any other object, well we'll damn well MAKE it an Integer anyway...and crash the program in the meantime.

    You realise that is the documented behaviour of Integer.compareTo() (and Comparable.compareTo(), for that matter). The real WTF there is that the implementation of this and equals() mean that x.equals(x) is false for IntegerType x, and x.compareTo(x) will throw a CCE.

    There is a possible reason for the existence of this IntegerType thing - Integer is final, and for some unknown reason he needs to subclass it. Hazarding a guess, he could be building a type hierarchy for xml schema (so there will be subclasses NonPositiveInteger and the like). Which isn't sensible either, but at least you can see what they were trying to do.

  • ullamcorper (unregistered) in reply to vereor
    vereor:
    Philipp:
    Ok, maybe, just maybe, and I am stretching here, there is a case where that code might make some sense... Have you ever tried to do this:

    Integer a = new Integer(11); Integer b = new Integer(11); System.out.println(a == b);

    (yes "=="; not equals). What do you guess will be the result? Depending on your VM implementation, this will most certainly yield --- true... Maybe the developers of the above code didn't want that and thus always compared something like new IntegerType instead...

    But really: Who cares? WTF...

    NO IT WILL NOT. EVER. It will always be false. It will never depend on the VM. Never never never.

    You could mean either boxing or valueOf. Then the -128 to +128 (or something like that) will always be true, the rest will depend on the VM. But if you see "new" it will ALWAYS be a new object. Always.

    I guess you could mean a different (none Java) VM. Then yes, your VM could shoot My Little Ponies out its arse every five minutes. But such behavour is not speced in the JVM. The JVM spec does state what happens when the keyword new is used.
  • Justin (unregistered) in reply to delenit

    It would save a lote of mallocs, no matter the scope :-)

    captcha: ludus, multiple of luda, cause I'm at the top of my game.

  • (cs)

    TRWTF would appear to be that they didn't comment the method to say why it existed; which seems to be to avoid boxing and unboxing and the gc overhead associated with it.

    Lack of comments is always a WTF, unless your method is full of them. In which case your method is probably overly complex and you should be looking at refactoring. Methods should be succinct.

    I'll stop rambling now.

  • Osno (unregistered)

    IntegerType is good for future-proof systems. If you always use IntegerType and at some point in time need to change the way integers work (say, make integer divide round up, or whatecer) you simply go and change the implementation. I don't see the WTF.

  • Steenbergh (unregistered) in reply to stanbeard
    stanbeard:
    Exactly! All instances of 1 and 0 point to the same static values. If you use a lot of 1s and 0s it seems like this would save a lot of memory.

    To accomplish this, they maintain a library that can cast any given object to binary blobs.

    CAPTCHA DomainConstants.INTEGER_0 (no, really)

  • natte (unregistered) in reply to Osno

    CommonUtils.getIntegerValueOf is fine or maybe a minor wtf depending on when it was written. And people saying that there is no point for that kind of optimization need to realize that Java is not just for "taking stuff from the database and sending it to browser".

  • abstract protected synchronized final void longSignature() (unregistered) in reply to stanbeard
    stanbeard:
    Exactly! All instances of 1 and 0 point to the same static values. If you use a lot of 1s and 0s it seems like this would save a lot of memory.

    You have ones and zeros? Once I had to write an entire database using only the letter 'O'.

    (Thanks to Scott Adams)

  • Yanman.be (unregistered)

    I'm going for: Paid By The Line©

  • (cs)

    The first one is a mistaken attempt to prevent heap fragmentation by preventing the creation of many Integer objects for the integral values 0 and 1. It's a mistake because Integer.valueOf() already does this, and has done since the earliest days of Java.

  • (cs) in reply to abstract protected synchronized final void longSignature()
    abstract protected synchronized final void longSignature():
    You have ones and zeros? Once I had to write an entire database using only the letter 'O'.
    "Why in my day, we had to XOR our forward and backward lists pointers into the same word!"

    "You had XOR? Luxury!"

  • (cs) in reply to Steenbergh
    Steenbergh:
    To accomplish this, they maintain a library that can cast any given object to binary blobs.

    Is that... like... extra binary?

  • Ummmm No. (unregistered) in reply to The Doubtful Guest

    You're an idiot. I'll let you figure out why... but I doubt you can.

  • (cs) in reply to stanbeard
    stanbeard:
    Exactly! All instances of 1 and 0 point to the same static values. If you use a lot of 1s and 0s it seems like this would save a lot of memory.

    The java.lang.Integer class already does this - as someone else pointed out, it now does it for all the values from -128 to 127.

  • (cs)

    It's a wrapper for a wrapper class. Incase the first class didn't fully wrap an int and there was like a 0 or a 1 sticking out.

  • thinkaboutit (unregistered)

    To criticize CommonUtils you would really have to know when this was implemented. Maybe they used mainly 1 and 0 and instantiation was so heavy operation at that time that they decided to cache those instances. In java 1.4 they introduced Boolean.valueOf(boolean) for this very purpose, so yo can avoid calling new Boolean(boolean) when new instances are not required.

    Also the IntegerType is impossible criticize, I mean was it even used anywhere? If it was then what way? I don't see how this could ever be used, but that doesn't mean that it couldn't. Almost anything taken out of context looks funny.

    Neither of these pieces of codes makes me go WTF, mainly just W.

  • (cs) in reply to delenit
    delenit:
    stanbeard:
    Exactly! All instances of 1 and 0 point to the same static values. If you use a lot of 1s and 0s it seems like this would save a lot of memory.
    Only if the 0 and 1's have a large scope.

    The article said they were static declarations in an interface, so they have classloader scope - very large in other words. It's still a WTF, as the Integer class has static instances for Integer(0) and Integer(1) already.

  • j (unregistered) in reply to Vechni
    Vechni:
    It's a wrapper for a wrapper class. Incase the first class didn't fully wrap an int and there was like a 0 or a 1 sticking out.

    Ah, I get it now, it's a wrapper for an int with a compound fraction...

  • (cs) in reply to j
    j:
    Vechni:
    It's a wrapper for a wrapper class. Incase the first class didn't fully wrap an int and there was like a 0 or a 1 sticking out.

    Ah, I get it now, it's a wrapper for an int with a compound fraction...

    Compound fractions can be nasty. You definitely want to get a wrapper on them before they get infected and go gangrenous. Otherwise you might have to amputate the entire int.

  • (cs) in reply to thinkaboutit
    thinkaboutit:
    To criticize CommonUtils you would really have to know when this was implemented. Maybe they used mainly 1 and 0 and instantiation was so heavy operation _at that time_ that they decided to cache those instances. In java 1.4 they introduced Boolean.valueOf(boolean) for this very purpose, so yo can avoid calling new Boolean(boolean) when new instances are not required.

    Boolean.valueOf(boolean) was only added for completeness - prior to that, you should have been using Boolean.TRUE and Boolean.FALSE. There's even a case for marking the Boolean(boolean) constructor deprecated, along with the default String() and String(String) constructors.

  • damnum (unregistered) in reply to Justin
    Justin:
    It would save a lote of mallocs, no matter the scope :-)

    captcha: ludus, multiple of luda, cause I'm at the top of my game.

    No it will not. It will save the GC, but the memory is already assigned to the app.

  • (cs) in reply to Anonymous
    Anonymous:
    At that time main memory of PCs where usually <= 256 MV

    WhoTF measures memory in megavolts?

    Edit: Wow, that was quite an alliteration.

  • abico (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    delenit:
    stanbeard:
    Exactly! All instances of 1 and 0 point to the same static values. If you use a lot of 1s and 0s it seems like this would save a lot of memory.
    Only if the 0 and 1's have a large scope.

    The article said they were static declarations in an interface, so they have classloader scope - very large in other words. It's still a WTF, as the Integer class has static instances for Integer(0) and Integer(1) already.

    The scope of the 1 & 0s this function created.
  • Anonymous (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    It's still a WTF, as the Integer class has static instances for Integer(0) and Integer(1) already.

    Show me where!

  • Anonymous (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    The first one is a mistaken attempt to prevent heap fragmentation by preventing the creation of many Integer objects for the integral values 0 and 1. It's a mistake because Integer.valueOf() already does this, and has done since the earliest days of Java.

    Java had an Integer.valueOf(String) - which creates a new Integer anyway - since very early. But Integer.valueOf(int) was added in Java 5. So it's still no WTF.

  • (cs)

    Yeah, CommonUtils looks like an atempt to reduce heap fragmentation. The WTF here is that, well, if he needs that level of optimization, why is he using Java? Really, rewrite the inner loops on C++, save Java for the low impact stuff (or buy more RAM).

    Oh, and by the way... Please tell me that DomainConstants.INTEGER_0 is 0 and DomainConstants.INTEGER_1 is 1. I can't really be sure.

  • (cs) in reply to abico
    abico:
    java.lang.Chris;:
    delenit:
    stanbeard:
    Exactly! All instances of 1 and 0 point to the same static values. If you use a lot of 1s and 0s it seems like this would save a lot of memory.
    Only if the 0 and 1's have a large scope.

    The article said they were static declarations in an interface, so they have classloader scope - very large in other words. It's still a WTF, as the Integer class has static instances for Integer(0) and Integer(1) already.

    The scope of the 1 & 0s this function created.

    The function (well, method actually) in the article doesn't create the Integer objects for the values 1 and 0. They are created once when the virtual machine loads the interface they are declared in, as they are declared static.

    There is actually a case for this method in code that is expected to run on Java 1.4 or older, as the Integer.valueOf(int) method was only added in Java 1.5, and the only valueOf methods before then expected String arguments. However, in Java 1.5, the call to the Integer(int) constructor becomes a nasty "feature", and Java doesn't support conditional compilation of code.

  • Christoph (unregistered)

    The real WTF is how many people, who obviously don't know anything about how Java works, try to argue in the comments that this is a WTF.

  • (cs) in reply to Anonymous
    Anonymous:
    java.lang.Chris;:
    The first one is a mistaken attempt to prevent heap fragmentation by preventing the creation of many Integer objects for the integral values 0 and 1. It's a mistake because Integer.valueOf() already does this, and has done since the earliest days of Java.

    Java had an Integer.valueOf(String) - which creates a new Integer anyway - since very early. But Integer.valueOf(int) was added in Java 5. So it's still no WTF.

    The Integer.valueOf(String) and Integer.valueOf(String, int) methods were the ones I was referring to. So for pre-1.5 code you would write Integer.valueOf(String.valueOf(int)), which adds an extra method call, but the String.valueOf(int) method would probably return the same intern'ed string object for "0" and "1" every time. Integer.valueOf(int) should have been part of the Integer class from the start though!

Leave a comment on “CommonUtils and the Inadequate java.lang.*”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article