While CPUs are hitting "90nm walls" and Moore's Law seems to be under some duress, graphic processing units (GPUs) have continued to dramatically increase their performance with each new generation. New GPUs are programmable at the pixel level, offering astonishing graphic capabilities without bothering the CPU. Fortunately, Java is along for the ride, thanks to the JOGL project.
JOGL, hosted on java.net and supported by Sun's gaming group, provides a Java wrapper to the popular and widely supported OpenGL graphics API. In other words, it allows Java applications to make calls to graphics hardware in much the same way that native code would. And with all the heavy lifting being done in hardware, it significantly narrows the performance gap between Java and languages like C and C++.
JOGL was started in the summer of 2002 by former MIT graduate students Ken Russell and Chris Kline. Russell says the goal was simply "to access the most leading-edge graphics technology from Java." That meant using OpenGL because of the wide support for OpenGL by various graphics-card manufacturers. There were other projects at the time with similar goals, but each had significant drawbacks-- incompatibility with AWT and Swing, incomplete support for standard and vendor-extension OpenGL calls, etc. So over the course of many evenings and weekends for nine months, the two began what they call a "skunkworks" project to build an OpenGL layer with that met their requirements.
As the project came along, Russell and Kline showed their work to the gaming group at Sun, which adopted it as their OpenGL story for Java. When java.net premiered in June 2003, JOGL made its public debut as one of the first big projects on the new site.
The JOGL project released version 1.0 in April 2004, but kept working. 1.1, currently in beta, supports full-screen anti-aliasing, among other features. Russell says that while the version numbering is arbitrary, advancing to version 1.1 is also meant to warn developers of some API changes.
Another significant new feature is multi-monitor support, which JOGL picks up by way of working with Java's AWT. Russell says that while JOGL's internals required some cleaning up to work with AWT, it was worth it to expand the realm of possible JOGL applications. "It expands the scope of the applications you can write," he explains, because while similar libraries "are optimized for single-screen games, while we can do modelers, CAD/CAM ... multi-monitor applications."
Uses and Possibilities
"I don't have a 10,000-foot view of the market," says Russell, "but OpenGL seems to be the best API for doing even 2D, hardware-accelerated graphics. This is the best, most portable way to use OpenGL, and then add in 3D if you like." Eventually, he says, applications like Studio 3D Max and Maya could be done in Java, thanks to JOGL.
Of course, high-performance 3D graphics still comes back to games, and JOGL excels in this field. German developer Bytonic ported the Quake II engine to Java by way of JOGL, calling it Jake2. This is a "remarkable feat," according to Russell, due to some "C-isms" that don't necessarily translate easily to Java. Despite this, the final product runs at 85 percent of the speed of the optimized C version--conventional wisdom about Java performance notwithstanding.
In fact, it gets better: while the Quake II engine was state-of-the-art in its day, newer graphics engines push more of the work off of the CPU and onto the GPU. This raises the possibility that JOGL-powered Java games could close the gap with C even further.
Much of the work currently done with JOGL consists of scene-graphs put atop JOGL, allowing developers to use a higher-level API. One popular example is Xith3D, which closely resembles the older Java3D API, but is more aligned with the needs of game programmers, providing better gaming performance.
While commercial uses of JOGL are hard to spot--game developers aren't typically in a hurry to tell competitors what technology they're using--Java/JOGL does offer an appealing alternative to buying expensive middleware that may or may not make ports between platforms possible. One thing that Russell said would be "really cool" would be to have Java support on the gaming consoles, and have high-performance game titles that are bytecode-compatible on different platforms out of the box. Or maybe there wouldn't even be a box--with Java's superb network support and security architecture, games (and their expansion packs, team roster updates, etc.) could be sent across the network directly to the end user's machine.
The JOGL Community
Russell says that the JOGL community on java.net is particularly active, making for the most active message forums on the javagaming.org site. The community is particularly effective at testing JOGL on a wide variety of graphics hardware, exposing JOGL to a greater number of configurations than would ever be practical to set up in a lab. He notes that the best bug fixes come from the community.
That said, to keep JOGL "close to product quality," the number of developers with commit access to the project has been deliberately kept small. Those that show an ability to work with the existing code base and make improvements without causing collateral damage are allowed in. But the project has clearly been changed by exposure to its active community. Russell says the reporting from the community "allows us to understand where the problems lie in the source base," and makes them expose JOGL to testing on real-world hardware rather than "going feed forward and assuming that everything will work great."
The Future of JOGL
Currently, the beta-quality JOGL 1.1 provides support for OpenGL and "most if not all vendor extensions." These include specific optimizations and features for ATI and Nvidia hardware, along with some other extensions that happen to be present on more or less all hardware. "The users clamored for it," Russell explains, "so we put it in the extensions portion of JOGL."
As far as what he'd like to tell the java.net community, Russell says he'd like to thank everyone for their work on the project and for their support. He encourages everyone interested in JOGL to continue to send reports, demos, and other applications built with JOGL and, if possible, to get involved with the technical side of the project, by checking out the code and working with it. "The more eyes that are on the source code, the better it will be."