Adventures with Karma
So I got my Karma replaced. They were actually stunningly efficient; I
called, got an RMA number, sent it to them and had a new one, all in
under a week.
Now, naturally, I want to put some songs on it. Previously I'd used
the Java app it comes with to do this from OS X, and that worked
fine, except that it's slow. On an 11mbps wireless link, it
takes about a minute per ~5MB song. It should take at most
6 or 7 seconds; 802.11b (with good signal strength) is faster than
1MB per second (which is still faster than USB 1.1, which is my
other alternative).
The funny thing is, I used the Java app on a friend's Windows machine
at Christmas, and it was nice and snappy, so I guess Mac OS X's Java
VM has super crappy networking or something. So I figure hey, this is
Java, right? I'll just run it in Linux; maybe the VM there has better
networking. You can actually get a Java VM for Linux/PPC from IBM..
except that when you try to run the Karma transfer program it dumps
core. Great. Write once, run anywhere my ass.
So then I see libkarma. Looks
promising.. except that it's horribly written, segfaults all over
the place and does fun stuff like returning pointers to buffers on
the stack. So then I just cut my losses and write a simple app using
WvStreams to copy
files to the Karma, and guess what? It doesn't take a minute per song!
I don't know why people haven't done more with the Karma. It's
got networking for crying out loud! And the protocol is
documented! You can definitely do some cool stuff with that, so it's
surprising nobody has, especially since people have written gnome-vfs
backends and KIOSlaves for the Rio 500. Anyway, my plan is to write
a fuse filesystem for it so I can just mount the sucker.
Moral of the story: don't buy a Karma unless you really like
tinkering.
Work
Was super busy for a while, but a bit less so now. It looks like I'm going
to have to write a bunch of Java code soon-ish, which will be, uh,
interesting, since I've not written any Java code in years.
In an effort to re-familiarise myself with Java today, I've been looking
at the new generics implementation in Java 5 (apparently that's the
correct thing to call it; will Sun ever stop having rediculously stupid
version numbers?)
It turns out that to support backwards compatibility, they've used
erasure to implement generics in Java. So you can do this:
public String joinStrings(Vector<String> listOfStrings, String delim);
And then if you pass it just a Vector, or a
Vector<Integer>, you'll get an error (which is what
you want).
But then you can also do this:
public String joinStrings(Vector listOfStrings, String delim);
And pass in Vector<Integer> if you like. I can see
that if you want old class files and old code to work on the new VM
and with the new compiler, you need this kind of thing, but it makes
generics considerably less useful.
Another nice tidbit is that you can never do new T();
inside a generic class, because the type information is gone, so
the compiler doesn't know if the type replacing T provides a
no-parameter constructor. So what you see is that
in the actual JDK, the code written by engineers at Sun, they're
doing nasty things like T[] foo = (T[])new Object[size];
The other way around this is to pass in a Class object of the
appropriate type:
public class Generic<T>
{
Class<T> tClass;
public Generic(Class<T> tClass)
{
this.tClass = tClass;
}
public void Foo()
{
T myT = tClass.newInstance();
// ... do stuff with myT
}
}
Yeesh. It seems like there are a lot of these kinds of things in Java;
things you want that are there, but only in a half-baked, semi-useful
way.
Notice that I dissed Java without even touching on the GC or VM.
Those are old, old debates and everybody has opinions on them, so
whatever.. apparently that stuff is better these days, but I have
no idea.
