[specialist]

I rank discontinuing HotJava as one of Sun's biggest missed opportunities.

The stackexchange commenter moans about graphics performance in Java. I helped write the Magician OpenGL bindings for Java in the '90s (the Java API side was all me, which Sven of JOGL basically copied). My VRML browser was just as fast (fps) as the available VRML browsers written in C/C++. With JDK 1.1.

Nowadays, Java and OpenGL go together like peas and carrots. Exhibit A is MineCraft.

A good buddy of mine does all his projects in Java and OpenGL. The latest is the awesome 2D skeletal animator called Spine at http://esotericsoftware.com. I couldn't imagine him doing it on top of any other stack.

[eropple]

> My VRML browser was just as fast (fps) as the available VRML browsers written in C/C++. With JDK 1.1.

With respect, I find your claims dubious. I would certainly buy that your top framerate was competitive. I also expect that your framerate was significantly more stuttery and inconsistent due to garbage collection (or else written in such a devolved form of Java that you really might as well write C++ anyway).

The problem is not Java's execution speed. It's that garbage collection is the death of responsiveness.

> Nowadays, Java and OpenGL go together like peas and carrots. Exhibit A is MineCraft.

Minecraft's performance characteristics are pretty bad for the fairly trivial rendering work being done. (It's improved, but it's still not great.) And writing code with LWJGL/JOAL is gross relative to similar code in C++--I have done both. You don't get anything for tying yourself to the JVM except, in a weird and mostly self-destructive way, the 'freedom' from understanding your object lifetimes and deterministic destruction.

I've used libgdx and XNA/MonoGame extensively and have gone back to C++ because both are fairly limited in their usefulness. libgdx helps by hiding a lot of nasty API issues--and Mario and company are super good at what they do--but what it gives you is generally taken away by the limitations of the JVM in a client context (limited platform support, the infuriating Dalvik/Hotspot divide, That Frigging GC Again...). Writing up some pretty minor glue code between windowing, input, audio, and graphics isn't that bad. And, perhaps more importantly, you'll actually understand how it works. (I've spent the week fighting with OpenAL. I'm glad I did. I've learned a lot and can recognize the failure cases and can do something about them.)

> A good buddy of mine does all his projects in Java and OpenGL. The latest is the awesome 2D skeletal animator called Spine at http://esotericsoftware.com. I couldn't imagine him doing it on top of any other stack.

Spine's pretty impressive, but there's not much in it you couldn't do with ease with Cocoa/Obj-C[++] or Qt or even WPF and .NET. It's also a misleading example, though, because tooling generally has much looser latency requirements than user software and so the severe weaknesses of JVM client applications are less readily apparent than in an application that needs to hit 60fps all day every day.

[specialist]

expect that your framerate was significantly more stuttery and inconsistent due to garbage collection

Static scenes, simple eventing. Compile the screen graph to meshes, load textures, then move the camera around. No stutter.

The trick is to avoid the GC, not thrash the heap, don't create a lot of short-lived objects.

Implementing LOD would have sped up my browser quite a bit.

The other idea was to compile VRML's DEF prototypes to Java byte code, avoiding VRML engine overhead, in which case my Java would have smoked C/C++.

My conclusion was not that my stupid simple browser was amazing, but rather the "native" C/C++ implementations were terrible. By comparison, my browser was about 5 times faster than LiquidReality, another Java-based browser.

[rossjudson]

And these days you can go ahead and create quite a few short-lived objects without worrying about it, as long as they're elided by escape analysis.

With judicious use of off-heap memory for regular structures it's simple to erase much of the crap in the heap, and reduce already-tiny GC times even further.

Never dropping a frame is another goal entirely, though, and for that I still believe you need a separated rendering/animation mechanism.