- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
But it's hard to imagine that memory is the only issue here. Computational performance would still suck - they still need to be converted back to ints for the CPU to perform actual operations.
Admin
The TWTF here is that most people didn't realise that auto boxing and/or Integer.valueOf() features are not available prior to java 5. And say, if you are still working with Websphere 6, you'll stuck with java 4, then actually the method makes lots of sense.
Admin
Real programmers produce programs only out of 0's and 1's (and they had better be cached). All the rest are luxuries for the simpletons.
Admin
It was great because you got cross-platform graphics for free, and in a browser no less. When your alternative is a kludgy mish-mash of HTML and JavaScript, Java kicks ass.
Too bad it didn't catch on there...
Admin
Obviously the OP is missing the point. Once the developer who wrote these routines finishes overloading all the built in types, operators and language features they can add "built a compiler" to their resume. Right? </snark>
Admin
Admin
Except Integer.valueOf(int) was only added after 1.4. See javadoc for valueOf, in particular the "Since" part.
Admin
Note: java.lang.Integer is final. (They made damn sure you can't even remotely get into operator overloading.)
As to the predefined small number Integers: yes, ISTR there are internal constants for this purpose, but the API explicitly promises newly-allocated instances whenever you call the constructor. So there, obvious optimization, by docs not done by the compiler or the JVM.
Admin
Can I have another constant?
if ( value == 42 ) { result = DomainConstants.INTEGER_42;Admin
2nd one is a WTF. But I see worse... all the time
Admin
public static Integer getIntegerValueOf(int value) { Integer result; if ( value == 0 ) { result = DomainConstants.INTEGER_0; } else if ( value == 1 ) { result = DomainConstants.INTEGER_1; } else { result = new Integer(value); } return result; }This should have been written like this:
The author of the code obviously did not know that class Integer itself has a cache for commonly used values. Creating a new Integer object with "new Integer(...)" is bad, because it circumvents that cache, unnecessarily creating new objects.
Admin
Or maybe, just maybe, the code was written on Java 1.4.x which some of us are still stuck with.
Admin
All the cool kids also know that, when referring to the language as opposed to the runtime, Perl is capitalized.
Admin
The type or namespace name 'Comment' could not be found (are you missing a using directive or an assembly reference?)
Admin
Yeah, the earliest days... back in JDK 1.5. This method didn't even exist prior to that release.
Admin
public static Integer valueOf(int i) { final int offset = 128; if (i >= -128 && i <= 127) { // must cache return IntegerCache.cache[i + offset]; } return new Integer(i); }Admin
I sure hope they remembered to file a bug/task to make this fix in some future version of java where the implementation was improved, otherwise some random maintainer is doomed to stumble across it and think it was a WTF.
Admin
He's absolutely right. Before JDK 1.4 which added Integer.valueOf, this was the only way to prevent multiple instantiation of the same integer.
Admin
Well, if there's one thing you certainly can't trust a computer with, it's 1's and 0's. lol
Admin
What if the user wanted to cache just 0 and 1 and want a new instance for all other cases?
Admin
Yes..... But in fact not.
I submitted this one, and in fact, when they use 0 or 1, they use new Integer(1) and new Integer(0).
They only use it for OTHER values.
And when they want to get a 1 or 0 vaule, they use this one :
public static final Integer parseInteger( String str ) { Integer result = null; if ( CommonUtils.isNotEmptyString(str)) { result = new Integer( Integer.parseInt( str ) ); } return result; }
Admin
Found a good illustration of what I was talking about
public static Integer getArchiveYearDestruct(Typologie typologie, int yearEnd) { int year = typologie.getYearDestruct(yearEnd).intValue(); Integer result = CommonUtils.getIntegerValueOf(year); return result; }
guess what? typologie.getYearDestruct(yearEnd) already returns an Integer
Admin
I really should stop looking in that class.... I found something worth a peek. For all those talking about optimisation and boolean use, here you are !
public static Integer booleanToInteger(boolean bool){ Integer result = null; if(bool == true){ result = new Integer(1); } else { result = new Integer(0); } return result; }
or the mighty
public static final int parseInt(String integer) { return Integer.parseInt(integer); }
Admin
I haven't actually used Java but after reading these comments I'm highly motivated to stay as far away from it as possible!
Sweet scary Moses!
Admin
one word: FUTUREPROOFING
PS. I wrote that code!
Cheers, Jaden (Dominoes Chef)
Admin
Except that Integer.getValueOf ALREADY caches the numbers from -128 to 127, so this is not only pointless but you also add in additional tests which are unnecessary.
Not a big WTF, but still, this is not useful.
Admin
The "implementation" of equals is severely broken:
IntegerType one = new IntegerType(1); if (!one.equals(one)) { throw new EqualsContractViolation("identity"); }Integer realOne = new Integer(1); if (one.equals(realOne) && ! realOne.equals(one)) { throw new EqualsContractViolation("reflexivity"); }