Hi Cas,
We have considered making the OGL-based Java 2D pipeline sit atop some intermediate library, like LWJGL or JOGL, but those libraries offer way more than we actually need. We
have strict requirements in the JDK for things like performance, memory footprint, and start-up time, so we have to maintain tight control over what we’re doing. For example,
we dynamically load only the GL function pointers we will actually use to minimize startup and footprint costs, whereas an intermediate library would likely load all GL
functions. Also, we require tight integration with the native windowing system layer (visuals, drawables, etc), and intermediate libraries tend to abstract those issues out.
So I wouldn’t really consider it “doing everything from scratch”. Aside from the issues I mentioned, we’re open to the idea of layering on top of Java/OGL bindings, so that in
theory we could move the remaining native OGL pipeline code up into Java land. We’ll explore that down the road.
In the meantime, working with C isn’t terrible 
The reality is that sometimes we do have to resort to native code. But we try to minimize it whenever possible. For example,
I rearchitected a lot of the OGL pipeline for 1.5-beta2, so that more native code was moved up to the Java layer, where it is more managable and maintainable. Also, the new
XAWT (implementation of AWT for Linux/Solaris in 1.5) is almost entirely implemented in Java code, so it’s certainly within the realm of possibility.
Thanks for the question,
Chris
