Chaotic Java

It seems to me that the importance of garbage collection in Java (and other garbage collected languages) is disproportional to the explanations given about it. While there would be millions of articles when you look for JavaFX examples, there would be only a couple if you tried to search about the “Parallel Compacting Collector” mentioned in Sun’s memory management whitepaper.

Since I wanted to understand better how the garbage collection is currently implemented in the Java VM and to see what’s ahead, I’ve scourged the internet a bit and found many interesting articles and slides. With the searches, it became like the old saying: there is a lot of stuff you don’t know, but there’s even more stuff you don’t even know you don’t know. This post is my summary of what I’ve found, but this is just the way I understand the explained material in publications and whitepapers; if I’m wrong somewhere, please do correct me.

Continue reading »

Autoboxing, a feature which seems like it had squeezed into JSR 201, is a convenience feature which has its own bag of tricks. This feature seems to come as a complement to the major EoD feature in Tiger, Generics. Since generics can’t be used with primitives as their types (i.e. Can’t declare Collection<int>), their wrappers are used instead (Collection<Integer>). This is due to erasure, as most annoying things about generics are (such as reflection data, an old rant of mine).

It’s obvious to see how autoboxing provides ease of use: Just taking foo(Integer num) as an example, the difference between foo(5) and foo(new Integer(5)) is notable! To take another case as an example, a call to bar(Integer[] arr) is simplified, using the varags feature, from bar(new Integer[] { new Integer(1), new Integer(2), new Integer(3) }) to bar(1, 2, 3), so the ease of development provided by this feature is nothing to ignore.

There are things that are less obvious about this new feature, though:

Continue reading »

A lot has been said, written and blogged on this subject, I know. I’ll try to cover it from the disassembly angle, though, after going over the main points of this comparison.

Why use StringBuilder?

A good question deserves a good answer. See, the String class is an immutable class - It will never really change internally. When you use the operator + it actually generates code that does it for you, and if you use the concat(String) it is clearly stated that a new string is created.

Worthy to note is that all of String methods do not change the string itself, but rather return a new String. More than once I’ve seen people calling replace and wondering why it does not work - They had forgot to take the returned value as the new value!

StringBuilder? I thought it was called StringBuffer!

The sharp eyed might notice that in J2SE 5.0, a new class was introduced called StringBuilder, while up until then there was a class called StringBuffer. Well, StringBuffer is still there, and I’ve discussed their differences earlier as an aside of a different post.

Continue reading »