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", 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.
"Real" Java (i.e. SE and EE), however, is something entirely different. Since 1.4 (February 6, 2002) Java is pretty decent. 1.5 (September 30, 2004) improved performance again. And 1.6 (December 11, 2006) gave us another massive speed boost.
Additionally, there are now various game libraries such as LWJGL and jogl/joal/jinput. There is even a very good engine called jMonkeyEngine. And thanks to kappaOne's hard work LWJGL applets are a lot more usable now. Horray for progess!
Apart from the browser integration there is another big benefit; Java is cross-platform. Supporting Windows, Mac OS, Linux, and maybe even less popular operating systems - all of that with a single code base. It's that mythical WORA thing.
In theory all this sounds pretty good, doesn't it? But how feasible is Java really?
Well, you can't tell unless you port Quake3 (the base for Quake Live) to Java first. But there is actually something which comes pretty close: Jake2 - a Java port of Quake2.
Jake2 was put into an LWJGL applet. The pak file was stripped down to a minimum, which reduced the download to about 7mb. Pack200 and LZMA compression were also thrown in for good measure.
I participated in the secret experimental testing session a few days ago. Well, ok... we were just playing some deathmatch for the fun of it. But - and that's the important part - everything did work really well. The applet worked as intended and we got some good mindless fragtastic fun - with different operating systems on a wide range of machines spread across the globe. Even switching to full screen mode worked fine.
If you take a close look at the two screenshots you can see the FPS counters. The 640x480 applet reaches 175fps and 1152x864 full screen reaches 123fps at that position. No that impressive for a gaming rig, is it?
Well, that's the interesting point here. It wasn't a gaming machine. The screenshots were taken on a 199€ office machine with integrated graphics (ATI X1250). The GPU is the only bottleneck here. While Quake3 pushes more polygons, the frames per second won't be much lower since the overdraw isn't much higher. Quake3's rendering in general seems to be more optimized (more batching), which is quite advantageous if an OpenGL binding is used.
Nowadays you only need 60fps anyways since TFTs typically run at 60hz. Reaching this target with common low end hardware should be a piece of cake. Today Java would have been an excellent choice. While it's too late for Quake Live, we'll probably see other Java powered 3D web games in the future. Unlike Quake Live they will actually run in the browser (Quake Live is only launched from the browser).
For rather obvious legal reasons a link to the applet cannot be provided. It was only meant to be a private proof of concept and that will never change.