Do you remember those days you started programming? Back then all I had was a Commodore 16, one and a half bad books, and BASIC of all things. The really awkward kind with numbers in front. Incrementing by 10 every line in case you need to insert something later on. Drawing a Sinus curve took bloody ages. You could literally see how it was plotted pixel by pixel.
Later at school I had some C lessons. I liked C a lot. It was fast enough to do draw some odd effects in real time and the code looked so much better than C16 BASIC. Well, big deal. But back then it was truly the holy grail for me. I also got introduced to that odd algorithm stuff. Bubble sort. Gasp.
There aren't much details out there about Quake Live (formerly known as Quake Zero) yet. One of the few things that were made public a few months ago was that it won't be written in Java (nor ActionScript... haha... very funny). Some people were really happy about that. Java is slow after all, right? Even Carmack himself said so.
While it's true that Carmack said "Java is really slow"[1], he didn't mean Java in general but J2ME. And he's of course right - J2ME is slow and it really is a platform of pure horror. There are simply too many differences between all those handsets. Different resolutions, color depths, key layouts, features, extensions, glitches, processing speed, memory, and whatever else might get in your way - it gets in your way with J2ME. I salute to the bravery of everyone who's doing that stuff for a living.

Hierarchical structures are always rather hard to explain with words alone. You've to identify the key items and then lay out their relation to each other - two at a time. This can take a couple of sentences and you'll also have to carefully check if everything is at the right place.
But it doesn't stop there. The worst part is probably that every user will have to parse your explanation very carefully. Of course that only adds a few seconds to the whole process, but those seconds accumulate. Your thousands (or even millions) of users might have done something more important during that time. They could have picked their nose for example, which is an activity many people enjoy more than reading documentation.
Yes, it's true. Reading documentation is really that exciting. So, we really should try everything possible to make it as quick and pain free as possible.
Concatenation of Strings is very easy in Java - all you need is a '+'. It can't get any easier than that, right? Unfortunately there are a few pitfalls. One thing you should remember from your first Java lessons is a small albeit important detail: String objects are immutable. Once constructed they cannot be changed anymore.
Whenever you "change" the value of a String you create a new object and make that variable reference this new object. Appending a String to another existing one is the same kind of deal: a new String containing the stuff from both is created and the old one is dropped.
You might wonder why Strings are immutable in first place. There are two very compelling reasons for it:
Sun's MLVM aka "The Da Vinci Machine" caters for the needs of many compiled and interpreted languages. Since Sun already gathered a lot of expertise with the JVM it's going to be a sure hit. Reliability and performance will be equally excellent without a doubt. And of course it will also run Java.
Yesterday during his keynote at Sun Tech Days James Gosling announced that they hired Ted Leung (a long-time Python developer from OSAF) and Frank Wierzbicki (the lead implementer of the Jython project). Both are going to work full-time on Jython - an implementation of Python written in 100% pure Java.

In games or educational programs you often don't want real randomness. Unsurprisingly random it's often a bit too random. You may get some items several times in a row and others too rarely. It's either too easy or too hard. Balancing the weights is hard as well, because each run is too different. And if that wouldn't be already bad enough; it's also difficult to verify the results.
Note: The continuous shuffled sequence algorithm which I'll explain in the second half of the article can be easily ported to other languages. All you need are arrays (and a copy function or resizable arrays) and a random number generator.
Before I'll dive into shuffled sequences I'll outline the other issues of the obvious approaches. Because that's apparently more fun to do.
Batik 1.7 comes with SMIL improvements (it's almost complete now) and some SVG 1.2 features were added as well. Check out the change log for details.
Batik is pretty much THE reference implementation. If an SVG doesn't work there, chances are very slim that it will work elsewhere. So, even if you aren't a Java developer get it anyways. The SVG-Viewer Squiggle (which is basically just a demo of the toolkit) is a great tool for doing quick cross-checks if the rendering isn't consistent between different browsers.
Java's future looks bright - the magical Java SE 6 Update N is just around the corner. A modularized JRE (Kernel installation mode) for quicker downloads, more Java2D acceleration, applets running in a separate thread (which means no dreaded startup freeze anymore), and lots of other funky things.
But how well do things look right now? Good question. David Brakeen (the author of Developing Games in Java) generously shared some stats from Pulp Games (by the way the 1.4 compatible PulpCore framework is open source and pretty awesome).
The size of the sample is 3653 playing sessions (single day). Since versions prior to 1.4 account only for about 2% we can thankfully ignore 'em completely. That was about time, wasn't it?
The startup time of Java applets isn't all that great. If you place an applet directly on your front page, some users may not like it. Caspian from puppygames.net removed the (awesome) Puppy Invaders game for this very reason. It's a shame, really. So, what can be done about that?
The issue is the direct start of the Java VM without any user interaction or any indication of what will happen. Apparently there are two options:
The following piece of code is written in Java, but it should be easy to port it to other languages.
long lastFrame=0;
float yield=10000f;
float frameAverage=16f; //start with desired msec per frame
[...]
long timeNow = System.currentTimeMillis();
//rolling average for the last 10 time inputs
frameAverage = (frameAverage * 10 + (timeNow - lastFrame)) / 11;
lastFrame=timeNow;
//16f = for 16msec
//0.1f = damping value
//+0.05f ensures that it can grow faster after it ran flat out for a while
yield+=yield*((16f/frameAverage)-1)*0.1f+0.05f;
for(int i=0;i<yield;i++)
Thread.yield();