I really ought to sleep…

I just wanted t see if I still knew how to write a quicksort by hand. Checked it against “Intruction to Algorithms, 2ND ed.” afterwards and it actually checks out. 🙂

package net.leenarts.algorithms.quicksort;

import java.util.Arrays;

public class QuickSort {

public static void main(String[] args) {
int[] A = {3,8,5,9,2,7,4,6,2,9,1,4,2,7,5,4};
doQuickSort(A, 0, A.length -1);
public static void doQuickSort(int[] A, int p, int r) {
if (p

Really six more reasons to hate Java?

Some guy from Buenos Aires made a write-up bashing some features of Java. Let’s test the validity of his argument. Oh, I came across his post through programming.reddit.com.

Based on his gripes he sounds like a systems programming to me, and if your one of those: What kind of problems is he trying? Perhaps pick another language better suited for the job. He actually states this by saying Java is good for web programming, it sucks for what he’s trying to do.

Let’s start with the first one.

It has no unsigned types
He argues about this being a problem when reading unsigned bytes from input. Well according to my memory the inputstream classes support a read byte method which returns an int in the range of 0 to 255. No problem reading unsigned bytes there. It could hurt some people that you are wasting a few bytes though. Also, it does not matter when working with bytes alone.

The shit does start when you actually have to convert bytes to another type, then you need to start thinking about how to deal the signed-ness of bytes in Java. So in my opinion, always having signed types (except for the 16 bit char) can get nasty when doing systems programming. Not to mention the problems this might cause when having to take into account if you should work big- or little- endian. For networks this is no problem, TCP/IP makes sure everything is “network order” which is big-endian and hey Java is also big-endian. Fortunatly the new IO classes can handle byte ordering easily, just have a look at the API docs. Look for ByteOrder and the order methods on the various buffer types. (It really is straight forward stuff, make a buffer, set it’s byte order, start getting and/or putting.)

So yeah, unsigned types can be a pain if you’re doing things the old way (ie. java.io). The new way (java.nio) however makes handling byte orders dead simple, and unsigned bytes can be handled as well as well. The example he gives can still be a pain though, because you easily forget a bit shift, an addition, or a proper read/write of a single byte. I do wonder though if there isn’t a neat way around this.

You can’t inherit constructors
Yeah you can’t. It’s a choice. By requiring explicit constructors calling nothing but super constructors you prevent people from instantiating your class without circumventing the classes initialisation logic. For simple constructors it can look stupid though.

You can’t declare destructors
That’s because you don’t control your objects garbage collection either. You mark an object eligible for collection by dropping references to it, at the same time you could call some cleaning logic. A dispose method is a common pattern.

He states that he had to write stupid finally blocks in his wrapper class. WTF man, add better exception handling. Catch those, handle all you want and be done with it.

You don’t have a sane way of controlling the terminal
He starts yapping on about String security and finally gets to his actual gripe. You can’t hide a password typed on the console. Well, ehm, know your stuff, it helps: http://java.sun.com/javase/6/docs/api/java/io/Console.html

No, you can’t leave stdin/stdout/stderr fscking alone!
What about the get*Stream methods? Ok, your code does have to handle input on those. So you have to do some extra work instead of dumping stuff on the standard console.

No, you can’t handle signals
And then he says you can, because it’s undocumented in some sun package. Well, there’s a reason it’s in the sun package, you shouldn’t use it except when you really really know what your doing.

Lot’s of stuff claiming that Java is garbage, but in the end it comes down to a few misunderstandings, differences of opinion and missing some features in the JDK6 release. And above all, Java is NOT the obvious choice for systems programming. Better leave that to shell scripts, C code, python, Perl, Ruby or some other language.

I hope this post doesn’t qualify me as a Java Zealot. Because there are things I don’t like about Java. Maybe I’ll report about those some other day. 🙂

ANTLR J-Spring session approved

I recently got word from the NL-JUG that they have granted me a presentation slot based on my session proposal regarding ANTLR.

I think it will be a tricky session to pull of properly. I’ll have to make a guess about how much my audience will know about grammar definition, parsers and compilers. But hey, that challenge is part of the reason I made my session proposal.

More details will follow.

Near miss with phishing mail

Recently I came back from a snowboarding vacation. Only half an hour home after a 12 hour drive I had to check my e-mail.

Too bad I missed the sender and recipient address on an e-mail message. I f-ed up and clicked a link leading me to a PayPal phishing site. I logged in and the site asked for my credit card details straight up. WTF!?! PayPal wouldn’t do that.

I immediately changed my password for PayPal. They didn’t have time to harvest my account. But they sure tried, because PayPal has blocked my account and has me jumping through the usual hoops to let me prove I’m still in control of my PayPal account.

Sigh! Just when I was about to purchase MarsEdit. I never thought I would fall for one of those phising e-mails. But finally I almost missed one, I never thought I would be so stupid.

Moral of this story:

Always double check the links you click in e-mails.