Comment On CommonUtils and the Inadequate java.lang.*

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

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

    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.

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! >:-)

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.

public class CommentType {
Comment c;

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

CommentType.Post();

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

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...

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;

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.

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...

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

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.

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.

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.

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

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).

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 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.

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.

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?

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.

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.

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.

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.

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.

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)

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".

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)

I'm going for: Paid By The Line©

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.

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!"

Steenbergh:

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

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

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

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.

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.

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.

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.

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...

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.

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.

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.

Anonymous:

At that time main memory of PCs where usually <= 256 MV

WhoTF measures memory in megavolts?

Edit: Wow, that was quite an alliteration.

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.

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!

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.

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.

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.

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.

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!