The Daily WTF: Curious Perversions in Information Technology

2009-01-14 Reply Admin

java.lang.Chris;:
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!

So, it would be counterproductive to use valueOf(String) it pre-Java 5, because it would create a new Integer AND a new String every time. So your comment that Integer.valueOf() does it since the early days of Java is plain wrong.

2009-01-14 Reply Admin

Anonymous:
java.lang.Chris;:
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!

So, it would be counterproductive to use valueOf(String) it pre-Java 5, because it would create a new Integer AND a new String every time. So your comment that Integer.valueOf() does it since the early days of Java is plain wrong.

Oops, just saw that I didn't get your argument that String.valueOf(1) would be interned: no it wouldn't and you could easily check this first, before posting any more wrong claims here!

java.lang.Chris; · 2009-01-14 Reply Admin

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

Nowadays Java is usually faster than C++ as the bytecode can be optimised on the fly (by the HotSpot features for instance), whereas C++ code is optimised once at compile time. Google for "java faster than c++" to find a number of articles with benchmarks.

In the bad old days, a number of design decisions were made that with hindsight we now know were wrong. Hence why we have things like the ArrayList class that's preferred over Vector, and StringBuilder that's preferred over StringBuffer - in both cases the older classes were thread safe, but experience showed that most often they were only used in a single thread and that the synchronisation overhead was costly. Synchronisation can be added to the newer classes only where necessary - by using the java.util.concurrent classes in many cases.

Another thing that hindered Java performance was the lack of appreciation among many Java programmers of how String concatenation was costly in terms of memory use and heap fragmentation. The "Effective Java" book went a long way towards making programmers aware of that problem, and encouraged the use of a buffer instead.

Finally, when you compare the time it takes to write and test C++ code versus the time it takes to do the same in Java for the same application, Java wins every time.

2009-01-14 Reply Admin

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

Umm, on my machine, using the Sun JRE 1.6.0_07, the following code:

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

Gives the following output:

false
true

As any sane person would have expected.

2009-01-14 Reply Admin

java.lang.Chris;:
Mcoder:
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).

Nowadays Java is usually faster than C++ as the bytecode can be optimised on the fly (by the HotSpot features for instance), whereas C++ code is optimised once at compile time. Google for "java faster than c++" to find a number of articles with benchmarks

Synthetic benchmarks are meaningless. I have NEVER seen a program written in Java that performs better than its C/C++ counterpart. You can attribute that to poor implementation, old JVM, sunspots, or whatever, but in my experience, Java is NOT faster in the real world (the only place where it matters).

java.lang.Chris; · 2009-01-14 Reply Admin

Anonymous:
Oops, just saw that I didn't get your argument that String.valueOf(1) would be interned: no it wouldn't and you could easily check this first, before posting any more wrong claims here!

Judging by the sources:

http://www.docjar.com/html/api/java/lang/Integer.java.html http://www.docjar.com/html/api/java/lang/String.java.html

You're almost totally right. The one exception is if the value passed to String.valueOf(int) is equal to Integer.MIN_VALUE, in which case you get a reference to a static instance. But, ignoring that pedantic point, I stand corrected.

java.lang.Chris; · 2009-01-14 Reply Admin

Chris:
java.lang.Chris;:
Mcoder:
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).

Nowadays Java is usually faster than C++ as the bytecode can be optimised on the fly (by the HotSpot features for instance), whereas C++ code is optimised once at compile time. Google for "java faster than c++" to find a number of articles with benchmarks
Synthetic benchmarks are meaningless. I have NEVER seen a program written in Java that performs better than its C/C++ counterpart. You can attribute that to poor implementation, old JVM, sunspots, or whatever, but in my experience, Java is NOT faster in the real world (the only place where it matters).

Well we'll agree to differ then, as those "synthetic" benchmarks concur with my experience of replacing two large systems written in C and C++ with Java based ones. Performance, testability and maintainability were far better for the Java implementations.

(I do love the way that people use words like "synthetic" when describing benchmarks that don't agree with their preconceived world view).

2009-01-14 Reply Admin

Mr. Top Cod3r, sir I'm sure you are already aware that java.lang.Integer does this already.

2009-01-14 Reply Admin

This is not necessarily a WTF. If you've ever had memory pressure, and you end up with a lot of 1s and 0s in your data, this is a way of avoiding polluting your space with millions of objects when only two are required.

bonzombiekitty · 2009-01-14 Reply Admin

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. (See also string interning).
No WTF to see here, please move along.

If I understand correctly using Integer.valueOf(int) accomplishes the same thing. Doing that will cache values, which can be used again. Unlike new Integer(int), which creates a brand new object every time.

From the javadoc for Integer.valueOf(int): "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. "

Addendum (2009-01-14 11:00): OOps. looks like other people brought up the same thing.

MrEricSir · 2009-01-14 Reply Admin

Ah, but is it compatible with ObjectWrapper?

2009-01-14 Reply Admin

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. (See also string interning).
No WTF to see here, please move along.

The real WTF is that you're using a language(*) that allocates 32 bit PoD objects using a garbage-collecting memory allocator, and then you're whining about the craptastic performance of programs written in that language.

(*)yes, I know the differences between Integer and int, and you probably do too. Does the guy in the next cube over from you know? What about the person next to him? What about the person who supplied the libraries you're using, or the framework you're coding to?

2009-01-14 Reply Admin

Since Java 1.5 has been released 4 years ago, it is time to replace to CommentUtils.getIntegerValueOf(int) by java.lang.Integer.valueOf(int i).

The real WTF is to link to the Java SE 1.3.1 Javadoc which is eight years old... If you want to use a language that didn't change during the past decade use C, C++ or MUMPS.

2009-01-14 Reply Admin

mongolito404:
If you want to use a language that didn't change during the past decade use C, C++ or MUMPS.

I guess you forgot about C99 and C++0x.

2009-01-14 Reply Admin

... and C++03

2009-01-14 Reply Admin

after reading all the comments on the first page, I came to the conclusion that TRWTF here is Java itself.

2009-01-14 Reply Admin

If only Integer weren't a final class, I think one could simplify the IntegerType class to just one line of code:

public class IntegerType extends Integer;

2009-01-14 Reply Admin

Not a WTF.

This code is a nice way to avoid instantiating 0 and 1 as brand new objects. If you are using say a database that represents booleans with 0 and 1 and you have a large dataset, this could be a significant speed increase.

Also, this code would allow you to use == with autoboxing 9at least with values that are supposed to be boolean) without borking b/c you won't have more than one Object representing 1 and 0.

2009-01-14 Reply Admin

bonzombiekitty:
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. (See also string interning).
No WTF to see here, please move along.

If I understand correctly using Integer.valueOf(int) accomplishes the same thing. Doing that will cache values, which can be used again. Unlike new Integer(int), which creates a brand new object every time.

From the javadoc for Integer.valueOf(int): "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. "

Addendum (2009-01-14 11:00): OOps. looks like other people brought up the same thing.

This is the correct way to do it in JDK5, but Integer.valueOf(int) did not exist in previous versions. Sure, this code could (and should) be updated with JDK5 additions, but that doesn't make it a WTF.

2009-01-14 Reply Admin

DomainConstants.FIRST

Honestly, wake up people. Tsh.

2009-01-14 Reply Admin

java.lang.Chris:
Nowadays Java is usually faster than C++ as the bytecode can be optimised on the fly (by the HotSpot features for instance), whereas C++ code is optimised once at compile time. Google for "java faster than c++" to find a number of articles with benchmarks.

What a crock. This article alone hints at the massive runtime overhead of the language and environment if someone feels the need to optimize value boxing! Add in garbage collection and the fact that you have no choice about things going on the heap, and the tracking done for every single reference, and on and on. Gimme a break.

In C++ you can make really fancy wrappers for stuff that have absolutely no footprint overhead whatsoever. That's the tip of the iceberg.

2009-01-14 Reply Admin

java.lang.Chris;:
Chris:
java.lang.Chris;:
Mcoder:
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).

Nowadays Java is usually faster than C++ as the bytecode can be optimised on the fly (by the HotSpot features for instance), whereas C++ code is optimised once at compile time. Google for "java faster than c++" to find a number of articles with benchmarks
Synthetic benchmarks are meaningless. I have NEVER seen a program written in Java that performs better than its C/C++ counterpart. You can attribute that to poor implementation, old JVM, sunspots, or whatever, but in my experience, Java is NOT faster in the real world (the only place where it matters).

Well we'll agree to differ then, as those "synthetic" benchmarks concur with my experience of replacing two large systems written in C and C++ with Java based ones. Performance, testability and maintainability were far better for the Java implementations.

(I do love the way that people use words like "synthetic" when describing benchmarks that don't agree with their preconceived world view).

And I love the way that Java nuts continue bringing up benchmarks that are invalid. Just doing a quick search, I found these points:

1)"Some of the other differences include the compilation policy used, heap defaults, and inlining policy." Am I the only one who noticed the "inlining policy" thing? Considering "method call" was one of the most compelling arguments for his case (by orders of magnitude!), the fact that the methods being "called" are being called INLINE should mean something.

If you're allowed to turn on the java inliner, surely you can spare the time to turn on the C++ one as well (he used -O2, not -O3, for compiling the C++ apps).

Picked a bad compiler for code optimization (g++ is better for porting)
Many of the C++ tests are not optimized. That is, they use C++ features like the iostream stuff (cout, and friends) which is extremely slow. The C versions are available and very fast. C++ is pretty much just an extension of C. You don't need to use C++ features if they slow you down. Another one is the hash stuff. In the C++ hash benchmark there are some goofy mistakes made by using the brackets [] operator where it forces several unnecessary lookups. You can also substitute a better STL hashing function that is faster (like MLton's insanely fast hasher).
I just went through and tested the hash2 benchmark and found that I was correct. The C++ version slaughters the Java version (even in "server" mode). This is completely different than what this dude's page shows.

Here is the "correct" code for hash2.cpp:

Yeah, this guy is a great source for java vs gcc tests. "Some of the C++ tests would not compile. I've never been very good at decoding GCC's error messages, so if I couldn't fix a test with a trivial modification, I didn't include it in my benchmarks."

2009-01-14 Reply Admin

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. (See also string interning).
No WTF to see here, please move along.

Can't java.lang.Integer just use its static methods to avoid allocating Integer objects? Almost every transformation method has a static equivalent.

The Integer class probably doesn't pre-calculate all the cases. So, it is enough to run the static code on a simple "int" every time. No class object ever has to exist.

2009-01-14 Reply Admin

public class IntegerType { Integer i; ... }

I'm guessing this IntegerType class was created to effectively have a mutable-value (changeable) version of Integer. The Integer class methods were replicated simply as a convenience.

They didn't code a getter or setter for the wrapped i value, but it is clearly not private as is the underlying value of the Integer class, so it can be directly accessed from outside methods.

Use of a mutable integer object (or String, or ...) in an application could very well be warranted. I've used a similar construct myself in the past.

I see no WTF here if this was the intention.

2009-01-14 Reply Admin

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 compiler already handles storage optimizations. The time and effort to instantiate this IntegerType class is more work for the JRE than any memory savings. An "int" is 32-bits!

Since Java is an OOP language, most "int" variables will belong to an object. So, there are NOT many shared, constant 0 or 1 values.

As the fool who proposed this posted, a shared java.lang.String constant is useful. It takes some time and memory to make a String, and String is immutable once created. None of that applies to scalars like "int".

rudraigh · 2009-01-14 Reply Admin

TRWFT (is there a limit as to how many of these there can be for any given article?) is that nobody has noticed or commented on the new Irish girl!

HypocriteWorld · 2009-01-14 Reply Admin

BrianL:
public class IntegerType { Integer i; ... }
I'm guessing this IntegerType class was created to effectively have a mutable-value (changeable) version of Integer. The Integer class methods were replicated simply as a convenience.

They didn't code a getter or setter for the wrapped i value, but it is clearly not private as is the underlying value of the Integer class, so it can be directly accessed from outside methods.

Use of a mutable integer object (or String, or ...) in an application could very well be warranted. I've used a similar construct myself in the past.

I see no WTF here if this was the intention.

If this is the intention of the programmer, then I'll take the words of a previous poster: TRWTF is Java itself.

2009-01-14 Reply Admin

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.

I guess if you've only been coding Java for a couple of years that's true. "valueOf(int)" was introduced in 1.5:

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

2009-01-14 Reply Admin

durnurd:
Steenbergh:
To accomplish this, they maintain a library that can cast any given object to binary blobs.
Is that... like... extra binary?

It's like large BLOB objects. ;-)

2009-01-14 Reply Admin

rudraigh:
TRWFT (is there a limit as to how many of these there can be for any given article?) is that nobody has noticed or commented on the new Irish girl!

she's not nearly as good looking. just a lame booth babe

2009-01-14 Reply Admin

Andrew:
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 compiler already handles storage optimizations. The time and effort to instantiate this IntegerType class is more work for the JRE than any memory savings. An "int" is 32-bits!

Since Java is an OOP language, most "int" variables will belong to an object. So, there are NOT many shared, constant 0 or 1 values.

As the fool who proposed this posted, a shared java.lang.String constant is useful. It takes some time and memory to make a String, and String is immutable once created. None of that applies to scalars like "int".

Integer type is immutable

danixdefcon5 · 2009-01-14 Reply Admin

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.

Wait, your PC had 256 MegaVytes? What are those?

Mcoder · 2009-01-14 Reply Admin

Blob:
It's like large BLOB objects. ;-)

My biggest worry now is that, if you framework has a class named BLOB, your programs are doomed to create several BLOB objects during their lifetime.

2009-01-14 Reply Admin

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.

I use a LOT of 0s and 1s....In fact everything I do seems to end up 0s and 1s

PS: I wouldn't be surprised if something along thesxe lines has been saidf (I'm too lazy to check)

Someone You Know · 2009-01-14 Reply Admin

Binary:
PS: I wouldn't be surprised if something along thesxe lines has been saidf (I'm too lazy to check)

saidf? Is that like a speech synthesis version of printf?

Alexis de Torquemada · 2009-01-14 Reply Admin

java.lang.Chris;:
Nowadays Java is usually faster than C++ as the bytecode can be optimised on the fly (by the HotSpot features for instance), whereas C++ code is optimised once at compile time. Google for "java faster than c++" to find a number of articles with benchmarks.

ROFL! Put down the Kool-Aid for a moment and take a look at the Gentoo Language Benchmarks Game.

By the way, the "benchmarks" you are referring to is an old rant written by an agnorant (spelling intentional) Java code monkey, and was thoroughly dissected on Slashdot over four years ago.

Your argument about JITting is also completely bogus for several reasons. First, HotSpot mostly helps Java solve performance problems that a well-written C++ program doesn't have in the first place because templates can be and are used for high performance compile-time polymorphism. C++ is currently replacing FORTRAN in number crunching and other supercomputing because compilers have come a long way especially when it comes to templates.

Second, C++ can be compiled to bytecode for JITting as well, C++/CLI is one example. As a sidenote, Java can be compiled directly to native code, which just goes to show that you are the poor victim of the classical false dichotomy logical fallacy.

java.lang.Chris;:
Finally, when you compare the time it takes to write and test C++ code versus the time it takes to do the same in Java for the same application, Java wins every time.

Not if maximum performance or modest memory usage are requirements (and they often are). Also, Java's type system is too limited for writing highly reusable generic code. The euphemistically named "generics", which are just statically typechecked syntactic sugar for old boring object inheritance, just don't cut it. (Don't get me wrong, they are way better than nothing!) Templates may be ugly but they are far more powerful than what Java has to offer.

2009-01-14 Reply Admin

Actually "System.out.println(a == b); " will almost certainly return false in this case.

Remember you are examining the Object Reference value NOT the value of the object in this statement.

Or in other words, you are checking to see if pointer to Object a is the same as the pointer to Object b.

The only time this will equate to true is if both a and b are the EXACT same Object. Not the same value, but the SAME Object. This can happen if you assign them. (aka) a=b;

It can also happen as part of a compiler optimization to save memory space. This is what happens when you get true with the following code:

String a = "bob"; String b = "bob"; if(a==b){ //Will always happen because the compiler changed the //above lines to //String a,b = "bob"; //Which means that they both point to the same spot in memory }else{ //Never happens }

Ironically, the WTF here is that the IntegerType function will actually cause any IntegerType object to encapsulate the SAME Integer and not different Integers with the same value.

2009-01-14 Reply Admin

INTEGER_0 and INTEGER_1 are actually database login information. The code is obscured to protect from hackers.

2009-01-14 Reply Admin

java.lang.Chris;:
Chris:
java.lang.Chris;:
Mcoder:
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).

Nowadays Java is usually faster than C++ as the bytecode can be optimised on the fly (by the HotSpot features for instance), whereas C++ code is optimised once at compile time. Google for "java faster than c++" to find a number of articles with benchmarks
Synthetic benchmarks are meaningless. I have NEVER seen a program written in Java that performs better than its C/C++ counterpart. You can attribute that to poor implementation, old JVM, sunspots, or whatever, but in my experience, Java is NOT faster in the real world (the only place where it matters).

Well we'll agree to differ then, as those "synthetic" benchmarks concur with my experience of replacing two large systems written in C and C++ with Java based ones. Performance, testability and maintainability were far better for the Java implementations.

(I do love the way that people use words like "synthetic" when describing benchmarks that don't agree with their preconceived world view).

Two large systems written in c & c++ had presumably evolved over some time - with a vareity of coders adding a vareity of hacks over the years. I'm sure for most apps that have been around for years, even re-writing them in the languiage they were originally written in would allow you to increase performance, stability and mainatinability.
When you start from scratch you don't have to concenr yourself about how big a hack this might be, and the effort required. You can fix things properly. Assuming you have any sense (and possibly even if you don't), you probably managed performance increases because you realised where things were done inefficiently/unnecessarily.

If you didn't, the whole task of rewriting such applications seems useless, other than to make a point here.

(I do love it when people try to subtly attack pooster's they disagree with, jusrt to make the world believe their point absolutely must be better)

2009-01-14 Reply Admin

Gaspar:
Actually "System.out.println(a == b); " will almost certainly return false in this case.
Remember you are examining the Object Reference value NOT the value of the object in this statement.

Or in other words, you are checking to see if pointer to Object a is the same as the pointer to Object b.

The only time this will equate to true is if both a and b are the EXACT same Object. Not the same value, but the SAME Object. This can happen if you assign them. (aka) a=b;

It can also happen as part of a compiler optimization to save memory space. This is what happens when you get true with the following code:

String a = "bob"; String b = "bob"; if(a==b){ //Will always happen because the compiler changed the //above lines to //String a,b = "bob"; //Which means that they both point to the same spot in memory }else{ //Never happens }

Ironically, the WTF here is that the IntegerType function will actually cause any IntegerType object to encapsulate the SAME Integer and not different Integers with the same value.

Maybe it's time for you to read through some of the posts beforehand (esp[ecailly the ones that explain WHY the equality will return true for (certain) Integer objects. (I think someone even produced results that they claimed to have for actually RUNNING the code, not hypothesisng or guessing what might happen)

2009-01-14 Reply Admin

I am surprised! Usually Java gets bagged everywhere (especially sites like this).

I am absolutely flabbergasted how many people seem to have intricate knowledge (or at least opinion) of how Java works. Clearly the language has broader usage/support than I thought possible.

The end is nigh, people, flee to the hills!

Alexis de Torquemada · 2009-01-14 Reply Admin

java.lang.Chris;:
Well we'll agree to differ then, as those "synthetic" benchmarks concur with my experience of replacing two large systems written in C and C++ with Java based ones. Performance, testability and maintainability were far better for the Java implementations.

So you replaced badly designed systems written in C and C++ with better designed systems written in Java, and as a consequence, performance was also improved. You said it yourself: "Performance, testability and maintainability" - if the designs were equally good, there would be little if any difference in at least one of those characteristics.

I could just as well show that quicksort implemented in JavaScript is faster than bubblesort implemented in C++ for sufficiently large input sizes. I have no idea what that would prove, but it could be done. In fact, I have written an advanced prime sieve program in Haskell that would certainly outperform a naive C++ sieve by far. But I definitely wouldn't be so foolish as to believe that this was any indication of the relative performance potential of the two languages.

Zygo:
The real WTF is that you're using a language(*) that allocates 32 bit PoD objects using a garbage-collecting memory allocator, and then you're whining about the craptastic performance of programs written in that language.

I don't know whether it's still the case, but in Java 1.5, generic containers used Objects even if the element type was primitive, e.g. ArrayList<int> was actually ArrayList<Integer>. I'm not too fond of .NET generics either, but you have to give Microsoft credit for getting this right - .NET generic containers don't use boxing for (at least) the built-in value types.

Phlip · 2009-01-14 Reply Admin

My favourite part of the IntegerType code is that:

IntegerType a = new IntegerType(5);
IntegerType b = new IntegerType(5);
if (a.equals(b))
{
//stuff
}

will throw a ClassCastException. Ditto for compareTo.

2009-01-14 Reply Admin

Chris:
Synthetic benchmarks are meaningless.

Yes, but...

The problem is that a full production benchmark is equivalent to doing the development, test, deployment to full service and then support of an application in each of the languages being checked. With that, you get to measure all the trade-offs throughout (e.g. faster code versus faster development) and understand what is actually right for you, and is pretty close (conceptually) to running a full scientific experiment. It's also brutally expensive, so hardly anyone ever does it. Instead, we use small benchmarks to test specific features, and we (if we're honest) attach big health warnings to the results of the benchmarks.

(In my experience, though well-written C can out-perform Java, it can be a real challenge to determine what that well-written C looks like, especially when memory-usage patterns are non-trivial. Java's more costly in system resources, but if you can produce a correct program more easily then you've frequently got a win overall. Of course, even bigger wins can be had by using multiple languages with differing abstraction levels but that's getting out of the realm of benchmark "discussions" and into real world programming...)

2009-01-14 Reply Admin

Phlip:
My favourite part of the IntegerType code is that [the equals method, when used with two instances of IntegerType] will throw a ClassCastException. Ditto for compareTo.

Now we're starting to get something that actually merits the term "WTF!"

pink_fairy · 2009-01-14 Reply Admin

lmpeters:
If only Integer weren't a final class, I think one could simplify the IntegerType class to just one line of code:
public class IntegerType extends Integer;

Well, I think that's kind of the point, isn't it?

I believe it's time for Java 1.0xFF to introduce the concept of "temporary," as in overriding "final" for classes. Thus:

public final class IntegerType extends temporary Integer;

I think we can all agree that this is easily translateable into byte code, can only be used explicitly to break immutability where necessary, and obviates the hideous perceived requirement to aggregate like a wildebeest on heat that the OP suggests.

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

In the field of languages in general, this is not known as an "optimization." It's known as a "regrettable kloodge."

Java's not an especially attractive option for "taking stuff from the database and sending it to (the) browser," either.

Think "Green" and "Oak." Java was foisted on the world around fifteen years ago; dug deep to justify itself; and has never really been convincing outside either (a) evangelism or (b) job security. The goddamn thing's a mess and should be put out of its misery.

FTR, I'm not particularly a language bigot. I see value in C/C++/Assembler where appropriate. I use Perl for simplicity and for reliable cross-platform libraries (eg SNMP-Net). I use Python for elegant scripting. I'm reasonably happy with Javascript, in small doses, where appropriate. I'd use Haskell or OCamL or Scheme given the chance.

What I won't choose to use is Java. It's an insane language, in the same sense that insane human beings tend to paint themselves into a corner, produce delusional arguments in an attempt to persuade themselves that this is a good thing to do, and dribble all over themselves.

"Taking stuff from the database and sending it to browser?" Pah. From AWT 1.0 through Swing to whatever's new, jazzy, and fusion-orientated, it used to be that Java was great because you got cross-platform graphics for free. (I could go on about RMI, but why shoot a dead cow in the head?)

It's crap. Get over it.

The JVM is still pretty sweet, though. 'Bout time we saw comparisons between that and .Net ...

2009-01-14 Reply Admin

pink_fairy:
<snip> FTR, I'm not particularly a language bigot. I see value in C/C++/Assembler where appropriate. I use Perl for simplicity and for reliable cross-platform libraries (eg SNMP-Net). I use Python for elegant scripting. I'm reasonably happy with Javascript, in small doses, where appropriate. I'd use Haskell or OCamL or Scheme given the chance.
What I won't choose to use is Java. It's an insane language, in the same sense that insane human beings tend to paint themselves into a corner, produce delusional arguments in an attempt to persuade themselves that this is a good thing to do, and dribble all over themselves.
<snip> The JVM is still pretty sweet, though. 'Bout time we saw comparisons between that and .Net ...

I think you forgot Ruby in your list of 'I'm so cool' languages. All the cool kids are now claiming perl, python and Ruby as their languages of choice! (although it was cool how you chose a particular dialect of Lisp {Scheme})

2009-01-14 Reply Admin

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. (See also string interning).
No WTF to see here, please move along.

Yes... it's so non-WTF that Sun even decided to implement the same thing in Integer.java:

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

It is implemented so that all ints between -127 and 127 are cached in the internal static IntegerCache class.

2009-01-14 Reply Admin

certified java dev:
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. (See also string interning).
No WTF to see here, please move along.

Yes... it's so non-WTF that Sun even decided to implement the same thing in Integer.java:

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

It is implemented so that all ints between -127 and 127 are cached in the internal static IntegerCache class.

That's funny, I suddenly had a peculiar sense of Deja Vu'

2009-01-14 Reply Admin

The java.lang.Integer class is final, so MyInteger could be a way of working around that. So, for example, you could extend MyInteger with BrokenIntegerType() which throws NumberFormatExceptions in some weird cases, or extend MyInteger with MutableIntegerType() which has a setValue(int) method on it.

Ashamedly, I've followed a similar pattern for other classes such as java.io.File, or java.lang.Runtime. I know it sucks but I can't see a better way for unit testing against these kinds of classes.

CommonUtils and the Inadequate java.lang.*

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