The evils of Java

I'm currently working on getting saving/loading working.I'd just like to rant a bit about Java.

I know, it's nothing new. And the fact that I'm pre-crippling myself by using Java 1.1 will garner me no sympathy whatsoever. And I'm almost certainly approaching the problem from completely the wrong direction.

Thudgame is designed so that it'll connect through a socket, and send stuff to the server, and get stuff back. Java can do this fine.

Thudgame is designed to accept various things from the server. Depending on the first word of the line* (which will always be 7-bit ASCII), the remainder of the line will be in ISO8859-1 (Latin-1), UTF-8, or binary data encoded in Base64, or binary data gzipped and encoded in Base64. Four possible encodings.

Fair enough. Trivial, trivial stuff, in any normal language. You get a line (in all encodings, the line endings are the same), you tokenise it by whitespace (the same in all encodings), and you use the first word to establish what's being sent, and how to deal with all the other words.

But in Java, anything that becomes a String (or a StringBuffer) will be corrupted and munged into Unicode, so that's no use for binary data. Also, if it uses the wrong encoding (which it will 3/4 of the time if we haven't read the first word to tell us what the encoding is), then it throws an exception and goes a bit wobbly.

Fair enough, then, we want arrays of bytes. How can we read a line of un-formatted bytes in?

Well, back in Java 1.0, we could almost use DataInputStream.readLine(). Except that's deprecated now, and anyway, it returned a String.

It's been deprecated in favour of BufferedReader.readLine(). Unfortunately that also only does Strings.

But wait! There's StreamTokenizer! A whole class specially for splitting streams into tokens! But it stores the tokens as Strings.

What about Java's other tokenizer, StringTokenizer? Of course, it also only works on Strings.

OK, so we roll our own ByteTokenizer class from scratch.

We just read it in character by character, and stuff the bytes into a dynamically expanding byte array until the end of the line! But... there's no way to dynamically extend arrays.

But there's the Vector class! That allows you to add stuff onto the end! Except, it doesn't let you add bytes or other primitive types: only object references.

That's OK though, that's kindof like C. We roll our own ByteVector class from scratch!

Whoo! On the home stretch now! And we've only had to create two new classes! Now all we need to do is convert the array of bytes we've read in to the right kindof object, using the correct encoding.

On the way, we stumble over the fact that Java doesn't allow pass-by-reference. It just simply forbids it. It passes primitive types by value, and object references by value. So you can modify an object by passing it to a function, but you can't make it into a different object. This is important for arrays, because it means that you can't resize an array if you need to, in a function that it passed the array but doesn't return it.

So, we can use new String(byte[] data, int offset, int length, String encoding) with encoding set to "UTF-8" or "ISO-8859-1", and we've got our first two encodings.

Then we roll our own Base64/BZip encoding/decoding utility class (*), create a ByteArrayInputStream from the array, stream it through a reader in the utility class, and we've got decoded Base64 with optional BZip.

And that cost about 500 lines and multiple wasted days chasing down dead ends that turned out to be impossible. Sure, I could have kludged it in a lot fewer lines, but the classes here should be useful and reusable elsewhere.

Just in case you missed it there, that means that to read in a single line, I have to create a new ByteVector object, parse it character by character into an array, reallocating and copying into a new array whenever it runs out of space. Then scan through the array to find the first occurance of the space character, convert that slice of the array to a new String object in order to compare it to the command string, then convert the remainder of the array into a ByteArrayInputStream, chain it with a new Base64InputStream, and read it into a new byte array...

And that's just to read in a single line.

(Actually, I reuse the ByteVector, and do an array comparison with a bunch of short, static arrays, which saves me from tokenizing the main array, and from creating any Strings unless I need to, and a bunch of other simplifications. It even runs smoothly on my crusty old laptop when I spam it from the server. But still! Yuck!)

In PHP, it's far fewer lines, including three per encoding type to decode. Most importantly, the MASSIVE faff to read in the bytes is just a single assignment in the while(). Half a line. *sob* I hate you, Java.

while($line = fgets($sock, 512)) {
  if (substr($line, 4) === 'UTF8') {
    $str = utf8_decode($params[2]);
  }
  elseif (substr($line, 6) === 'LATIN1') {
    $str = $params[2];
  }
  elseif (substr($line, 6) === 'BASE64') {
    $data = base64_decode($params[2]);
  }
  elseif (substr($line, 10) === 'BASE64GZIP') {
    $data = bzdecompress(base64_decode($params[2]));
  }
}

[* I've actually simplified significantly for the sake of this rant. The encoding depends on multiple factors. The "command word" (third word in the line), is used to distinguish between the BASE64 binary data and the strings. The Byte Order Marker (BOM) at the beginning of the strings is used to distinguish between the two encodings (default is Latin-1), and the decoded value of the Base64 stuff is checked and it automatically uncompresses on the fly if it wants. The whole sexy Base64 magic is not something I can claim credit for: it comes from Mr Harder's work at http://iharder.sourceforge.net/base64/ ]