Comment On Primitive Wrapping and Unwrapping

OMFG

There must have been a total lack of understanding.
Theres no way somone who even has an IQ of 1 can do this.


When i think of it... Can the javac compiler optimize suchs things? I mean, it's pretty obvious isn't it?


captcha: java (how fittig...)

Hard-coding the value is a bit naughty, as well.

(I kid, I kid)

I've seen stuff just as bad in C#. Something along the lines of:

System.Convert.ToString("whatever " + something.ToString());

Well - for the first way to call someMethod, you surely mean:

int x = 0;
someMethod(x);

or

Integer x = new Integer(0);
someMethod(x);

*boggles*

The whole concept of having both a primitive type and an ADT for some types is hopelessly farked IMO, so this is more of a general Java WTF (and an OMG, add BBQ for good measure). Too see how it's done properly, have a look at Ruby.

The given example looks more like a case of Bored Programmer to me. Or, as the captcha says, genius.

Of course, any *real* programmer would know that you don't use 'magic numbers' in code :)

<quote>
Well - for the first way to call someMethod, you surely mean:

int x = 0;
someMethod(x);
</quote>

Unless he's been working with JDK 1.5 lately which supports automatic boxing/unboxing of primitives.

Without knowing what someMethod() does, it's hard to say if wrapping the native integer is necessary or not. Regardless of what someMethod does, the rewrapping is completely pointless.

For object-oriented languages, such as Java, there's some reason for having classes such as Integer and Boolean - mostly for storing those values in lists, trees, etc. that take Objects as arguments. Starting with version 5 (I believe), Java performs auto-boxing which performs automatic wrapping of native data types when necessary.

Theres no way somone who even has an IQ of 1 can do this.

Get it right!

It's an IQ of new Integer(1).intValue;

:)

The only thing I can really think of is an overreaction to Java's aliasing. By default, everything is passed by reference, so if you're not careful, you can get some really weird side effects. Could be that they're just going overboard on making copies.

They probably call it a 'design pattern'.

AT:

Unless he's been working with JDK 1.5 lately which supports automatic boxing/unboxing of primitives.

Ah. My l33t Java skills are obviously a bit rusty.. :)

Wouldn't the correct way be something more like:

private static final Integer ZERO = new Integer(0);
//better yet name it something more meaningful...
//or if your using java 5 change it from an int/integer to an //enumerated value

someMethod(ZERO);

Editor's note:Is this practice of wrapping/unwrapping variables being derived from languages that lack strong variable types, such as VBScript, or is it a complete misunderstanding of how variables and functions work?

It's probably somewhat of a combination, although I think more of the blame lies in VB6 and VBScript.

And I was annoyed by the idiom:

String hello = new String("Hello");

Don't you know the true l33t way is:

someMethod(Integer.valueOf(0));

Sheesh, read the doc. :)

why? at what point are you likely to redefine what zero is?
Do you define TRUE and FALSE as well?

Rob Briggs:

Of course, any *real* programmer would know that you don't use 'magic numbers' in code :)

So, the code should have been something like:

const one_or_maybe_two = 0; 

someMethod(new Integer(one_or_maybe_two));

I'd probably assume that code was auto-generated. By a horribly stupid auto-generator program, of course. But that's still more plausible than the idea that anyone wrote that by hand.

just a humble question from a non-java coder: why not just call someMethod(0); ? Ok, if it was an option, it would surely have been mentioned, i just want to know why, thx!

No, Integer x = 0; is alright as Java (from v5 onwards) does autoboxing

Paid by the letter

CAPTCHA: 1337

someMethod(0); // autoboxing version
or
someMethod(Integer.valueOf(0)); // I don't like auto boxing.

Don't forget that Integer.valueOf() helps with caching of Integer values. This would help with some memory usage.

Integer.valueOf() and Integer.parseInt() should become people's friends. There's never a need to ever call new Integer.

Looks like Cargo Cult Programming to me ...

http://catb.org/jargon/html/C/cargo-cult-programming.html

You forgot the third "boolean" value: FILE_NOT_FOUND.

Complete misunderstanding.

Java isn't an acronym.

Java isn't an acronym.

to richard: Because sometimes you need a null value also.

I've worked with VBScript for about three years (*shudder*), and I've never really used a wrap/unwrap/wrap pattern like that before.

Usually if you need to type a variable you can pass it to the CInt() method. So the VBScript example would be:

Dim x

Set x = 0



Call someMethod(CInt(x))

Tom:

The only thing I can really think of is an overreaction to Java's aliasing. By default, everything is passed by reference, so if you're not careful, you can get some really weird side effects.

No, in Java everything is passed by value.
http://javadude.com/articles/passbyvalue.htm
http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html
http://www.jguru.com/faq/view.jsp?EID=430996

You just have to remember that object variables are pointers to an object, not an object themselves. So passing an object variable to a method means you are passing a copy of the value of the pointer to the object, not a copy of the object itself.

Looks like someone needs to look up how to use enumerated types. Using magic numbers in code is very bad mmmkay.

Natrone:

Don't you know the true l33t way is:

someMethod(Integer.valueOf(0));

Sheesh, read the doc. :)

You've still used a magic number of 0 in there..

perhaps

someMethod(Integer.ValueOf(GlobalSettings.ReadSetting("ZERO"));

:P
Captcha Perfection

richard:

just a humble question from a non-java coder: why not just call someMethod(0); ? Ok, if it was an option, it would surely have been mentioned, i just want to know why, thx!

Because in Java, an "int" and an "Integer" are different data types. "int" is a primitive while "Integer" is an object. If someMethod was defined as:

someMethod(Integer i)
or
someMethod(Object o)

then passing an "int" would cause a compile time error in Java 1.4 and older. However, as mentioned already, Java 1.5 and up have auto-boxing, which will convert an "int" to an "Integer" and back when needed.

This is a hack because of the original decision to use primitives in Java, instead of making everything an object like they did in Ruby.

Possibly the result of copy-and-paste from code where the programmer was worried that the Integer object might be modified (if so, that's another WTF, of course).

Please, lets not go here. I see enough of these PBR/PBV discussions on the java forums. Java is always Pass-By-Value. The confusion is from the fact that when passing an object, it is the objects reference that is being passed by value, thus any changes to the to object made by using that reference are reflected in the original object.


~Tim

[captcha : awesomeness ] -- Yes, this post is full of it!

The first version will only work in Java 5 and up. Integer x = 0 can never evaluate unless autoboxing is on to convert it to an Integer.

Either way, this wrap-unwrap-wrap again method is just plain dumb.

thanks for clearing that up ppl, should have read the text more carefully =) i learned something today, yay!

There are so many things wrong with that its ridiculous.

As a native (to the US) programmer, makes me not worried about offshoring...

orangeyoda:

Natrone:

Don't you know the true l33t way is:

someMethod(Integer.valueOf(0));

Sheesh, read the doc. :)

You've still used a magic number of 0 in there..

perhaps

someMethod(Integer.ValueOf(GlobalSettings.ReadSetting("ZERO"));

:P
Captcha Perfection

Don't you mean:

someMethod(Integer.valueOf(GlobalSettings.readSetting(BOOLEAN.FILE_NOT_FOUND)));

richard:

thanks for clearing that up ppl, should have read the text more carefully =) i learned something today, yay!

So, TDWTF is educational?

I think I've produced code that looks kind of like this before, but it was in PHP, where this kind of what-type-is-it-really paranoia is frequently helpful.

M Harris:

There are so many things wrong with that its ridiculous.

As a native (to the US) programmer, makes me not worried about offshoring...

But the fact that an American CEO bought it based on power point slides and made American programmers support it should.

M Harris:

There are so many things wrong with that its ridiculous.

As a native (to the US) programmer, makes me not worried about offshoring...

I would be afraid... very afraid.

From the original posting: "To add insult to injury, the original programmers would blame Daniel and company whenever something went wrong because they "touched" (fixed) the original code."

Obfuscation == Job Security. The PHB doesn't know anything about inefficient code, he just sees that whenever the home team touches it, it breaks.

Oddly enough, I've had a great career writing easily-understood code with tons of comments. Go figure!

Editor's note:Is this practice of wrapping/unwrapping variables being derived from languages that lack strong variable types, such as VBScript, or is it a complete misunderstanding of how variables and functions work?

return new Boolean(True).boolValue

nFec:

(...)
When i think of it... Can the javac compiler optimize suchs things? I mean, it's pretty obvious isn't it?

Well, it doesn't :( Try this:

public static void main(String[] args) {
Integer a = new Integer(0);
Integer b = new Integer(0);
System.out.println( (a==b) );
}
..and you'll get 'false'.

OTOH this:
Integer a = 0;
Integer b = 0;

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

gives 'true'. Of cource the latter is valid in Java >= 1.5 only.

It's not just offshoring I object to, I object if a company I work for contracts out development work to any other company because there seems to be some automatic assumption that such developers are far more "expert" than anyone they might have in the company.

Well they often are more expert in their line of business but not always with regards to coding.

SomebodyElse:

Java is always Pass-By-Value. The confusion is from the fact that when passing an object, it is the objects reference that is being passed by value, thus any changes to the to object made by using that reference are reflected in the original object.

So Java is always pass by value, it's just that the value is sometimes a reference? Well, thanks for clearing that up.

I guess similarly, Ruby is always pass by value, it's just that the values are always references.

[Captcha: Java!]

Michael:

Tom:

The only thing I can really think of is an overreaction to Java's aliasing. By default, everything is passed by reference, so if you're not careful, you can get some really weird side effects.

No, in Java everything is passed by value.
http://javadude.com/articles/passbyvalue.htm
http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html
http://www.jguru.com/faq/view.jsp?EID=430996

You just have to remember that object variables are pointers to an object, not an object themselves. So passing an object variable to a method means you are passing a copy of the value of the pointer to the object, not a copy of the object itself.

Er... isn't a "pointer to the object" the definition of a "reference"? As in "pass by reference"? When you change the attributes of objects which are passed in, you don't change the attributes in a local copy, you change the original.

Mike Nuss:

Java isn't an acronym.

I capitalize JAVA not because it's an acronym, but because it is AWESOME!

It's really just a habit from typing language names which may include acronyms and abbreviations in caps, such as COBOL, FORTRAN, C, etc.

Marcin:

Possibly the result of copy-and-paste from code where the programmer was worried that the Integer object might be modified (if so, that's another WTF, of course).

Integer objects are immutable. It is not possible to modify the value of the primitive stored inside the object. Of course the programmer probably didn't know that...