3D graphics programming in Java, Part 3: OpenGL

Advantages and disadvantages to Java-to-OpenGL bindings vs. the Java 3D API implementation from Sun

It has been a while since our last installment in this series on 3D graphics programming in Java (more on that at the end of this column). Here's a quick refresher on what we were last discussing and where we left off.

In the previous two columns (see Resources), we explored Java 3D. We discussed static content and small scenes, then used larger scene graphs and built interactivity into some basic 3D worlds.

Now that you know a little bit about using Java 3D, it's time to compare and contrast the Java 3D approach to 3D graphics with the leading graphics API contender: OpenGL.

Please note that this article was originally intended to be code-intensive, but the late-breaking decision by Arcane Technologies concerning the Magician binding (see below) necessitated the removal of the code examples. I hope this article's content can be adapted for a future Java-OpenGL binding, as yet unavailable from the OpenGL Consortium.

In any event, I've endeavored to provide all the relevant and useful OpenGL-related references and URLs in the Resources at the end of this column. If you would like to dig further into Java-OpenGL, I strongly recommend that you review these references.

Java-OpenGL comparison with Java 3D

In previous installments on Java 3D, I provided a list of strengths and weaknesses of using Java 3D for graphics applications. Let's reprise that list, but do so by looking at the strengths and weaknesses of Java-OpenGL-based solutions instead of Java 3D-based solutions.

Strengths of using OpenGL (and, by extension and where noted, Java-OpenGL bindings):

  • OpenGL provides a procedural model of graphics

    This closely matches many of the algorithms and methods graphics programmers have used historically. The procedural model is at once intuitive and straightforward for many accomplished 3D graphics aficionados.

  • OpenGL provides direct access to the rendering pipeline

    This is true with any of the various language bindings, including most Java bindings. OpenGL empowers programmers to directly specify how graphics should be rendered. One doesn't just hint and request as with Java 3D, one stipulates.

  • OpenGL is optimized in every imaginable way

    OpenGL is optimized in hardware and software and targeted platforms ranging from the cheapest PCs and game consoles to the most high-end graphics supercomputers.

  • Vendors of every kind of 3D graphics-related hardware support OpenGL

    OpenGL is


    standard against which hardware vendors measure their graphics technology, bar none. As Microsoft has joined with SGI in the Fahrenheit initiative, it has become increasingly obvious to many that this is in effect Microsoft's indirect acknowledgment that OpenGL won the API wars for 2D and 3D graphics.

On the other hand, nothing is perfect. OpenGL, and certainly Java-OpenGL bindings, do have some significant shortcomings:

  • The strengths of the procedural approach to graphics programming are simultaneously a weakness for many Java programmers

    For relatively new programmers, many of whom may have received their first formal programming instruction in Java using object-oriented methodologies, OpenGL's procedural method does not mesh well with an object-oriented approach and good engineering practice.

  • Many vendors' OpenGL optimizations are meant to decrease hardware choice

    It is in each vendor's best interest to build proprietary extensions and make proprietary optimizations to sell more of its own hardware. As with all hardware optimizations, you must use accelerator-specific OpenGL optimizations with the understanding that each optimization for one platform diminishes portability and performance for several others. Java 3D's more general-purpose optimizations mostly aim to maximize the portability of Java 3D applications.

  • While C interfaces to OpenGL are ubiquitous, Java interfaces aren't yet standardized and aren't widely available

    Arcane Technologies's Magician product had until recently been in the market to change this portability issue, but with its demise goes much of the cross-platform story for Java-OpenGL, at least at present. More on this below.

  • OpenGL's exposure of the inner details of the rendering process can significantly complicate otherwise simple 3D graphics programs

    Power and flexibility come at the price of complexity. In the fast development cycles of today's technology world, complexity is in and of itself something to be avoided where possible. The old adage about bugs is true: the more lines of code, the more bugs (in general).

As you can see from the pros and cons for OpenGL-based approaches, Java-OpenGL is strong in many of the areas in which Java 3D is weak. OpenGL gives programmers the low-level access to the rendering process that Java 3D explicitly avoids, and OpenGL is currently available on far more platforms than Java 3D (Magician aside). But this flexibility comes with a potential price: programmers have a lot of room to optimize, which conversely means they have a lot of room to screw things up. Java 3D has more built-in optimization and an easier programming model that may prove particularly useful for programmers new to Java, 3D graphics work, or networked and distributed graphics programming.

Magician: Great but gone

Until very recently, the major choices for bindings for OpenGL programming in Java were:

  • Magician
  • GL4Java
  • JSparrow
  • OpenGL4Java and several of its derivatives (Jogl, Palevich Java/OpenGL bindings, Tree)

Note: This list is borrowed from the OpenGL Consortium's Call for Proposals for a standard for Java bindings for OpenGL.

The OpenGL Java Bindings Working Group considered Magician, JSparrow, and GL4Java during its review process for a standard for Java-OpenGL bindings. Prior to its discontinuation, Magician was the unacknowledged front-runner for the majority of the binding discussions.

Magician had a diverse and vocal user group, albeit perhaps somewhat smaller than Arcane would have liked it to be. Arcane was readying a new release of Magician, 1.2.0, which was slated to include the following (in no particular order):

  • Swing and JFC 1.1 integration via a lightweight OpenGL-aware component

  • Offscreen rendering support to work with Magician's standard heavyweight and new lightweight components

  • Enhanced capabilities support, including the ability to enumerate available capabilities (or visuals, in X Windows terminology)

  • Overlay support

  • Runtime OpenGL version checking

  • Some performance enhancements

  • OpenGL 1.2 compliance

Unfortunately, Arcane Technologies recently announced the discontinuation of Magician due to poor sales.

Arcane made this announcement on March 12, 1999, with the stated intent of removing various links to related information from its Web site on March 19, 1999. Some of the Arcane Technologies and Magician links in the Resources section may cease to function at some point because of this, though all are still live as of the date of this publication.

It is unclear how Magician's termination by Arcane will affect future work on a standard Java-OpenGL binding, though the traffic on the Java-OpenGL Working Group's mailing list has fallen off somewhat since the announcement was made.

Whatever the case may be, this is bad news for those interested in using the leading Java-OpenGL binding. Though Arcane has offered to license the technology to other vendors, we will have to wait and see if anyone takes the offer and makes Magician available again in future releases. If not, one can only hope that Arcane might consider making the Magician code available to the OpenGL Consortium for use as the reference binding.

Availability of OpenGL for Java

Many of the other Java-OpenGL bindings are available for Win32 platforms only, or at best for Win32 and Unix platforms. Magician, on the other hand, was available for many of the major development and deployment platforms targeted for PCs and workstations.

If Arcane can find some way to continue to make Magician available to the masses, the cross-platform portability of Java bindings to OpenGL will be greatly reinforced. Compared to the rather limited support from the other major bindings, Magician provided:




Linux glibcSun JVM, Cambridge OpenGroup, RedHat Sun port, KaffeMesa for all
Intel/SolarisSun, KaffeMesa for all
SPARC/SolarisSun, KaffeSolaris OpenGL, Mesa (respectively)
IrixSGISGI OpenGL, Mesa
Windows95/98/NTSun, Microsoft, SuperCede, Borland JBuilder, Symantec Cafe, Netscape NavigatorSGI OpenGL, Microsoft OpenGL, Mesa
Mac OSApple MRJ, Metrowerks CodeWarriorConix OpenGL, Mesa

As a reminder from the last two columns, Java 3D is currently available from Sun for Solaris and Win32 platforms. If and when Magician (or some other OpenGL Consortium-endorsed Java binding of similar portability) lives on, a Java-OpenGL-based solution would be far more portable across platforms than a Java 3D-based solution. If no standard Java-OpenGL bindings (re)emerges, portability is similar across Java-OpenGL and Java 3D and the design and development decision-making process should weigh the other technical and business aspects appropriately.

And, finally, as we were finalizing this article, Jean-Christophe Taveau announced the 0.1 availability of jFree-D, a Jogl-based Java 3D implementation built using GNU tools for Linux and IRIX, among various other platforms. This announcement has the potential to increase the portability of Java 3D considerably. More on this breaking news at the end of the column.

In the meantime, what choices do developers have for a Java-OpenGL binding? As of the writing of this column, you can download implementations of the following bindings for the listed platforms:

Java-OpenGL binding


GL4JavaUnix (tested by developer on Linux) and Win32 (tested on Windows NT)
JoglUnix (requires GNU make), and Win32
TreeInterface to Mesa OpenGL-like library for Unix, Win32, other Mesa-supported platforms
OpenGL4JavaA port of most OpenGL C functions to Java for platforms with OpenGL or Mesa implementations
JavaOpenGLWin32 (uses OpenGL32.dll from Microsoft)

(See Resources for download information.)

As you can see, many of these implementations are supported for both Unix and Win32, and work with Mesa and/or licensed OpenGL implementations. What you will notice if you visit the individual implementations' Web sites, however, is that many of them haven't developed much further since they were introduced around 1997. The reason for this? Magician has taken the mindshare and expanded upon the capabilities of the other Java-OpenGL bindings, most of which are freeware or shareware efforts.

Given that these other bindings aren't undergoing active development, you should make your choice based at least in part on the availability of the source code and your ability to license and modify it. I would suggest verifying that you will have the capabilities you need before you start doing any significant coding: you wouldn't want to move from Magician to one of these other bindings only to find it removed from the Web and distribution, again locking you out of doing further work on your application.

Case Study: Why SynaPix chose Java-to-OpenGL

Magician's financial viability issues aside, there are some good technical reasons to at least consider using a Java-OpenGL binding in lieu of Java 3D. Java bindings have succeeded in some markets. Though Arcane may not have found enough customers to keep Magician afloat, the technology nonetheless has found some ardent supporters in the graphics development community.

Barry Ruff of SynaPix had the following to say of his company's choice to use Magician's Java-to-OpenGL bindings. (These comments were made before Arcane's announcement about Magician's termination.)

SynaPix is developing a visual effects workstation product called SynaFlex. SynaFlex analyzes film and video footage and creates 3D representations of a given scene. The scene is then combined with synthetic objects in a single 3D space where a variety of techniques can be used to merge 2D and 3D elements. The SynaFlex system is about 90 percent written in Java. In a large part that is due to the Magician API.

SynaFlex was originally going to use OpenGL and a higher level scene graph representation like Optimizer or Performer and then use Java for its UI. But after some initial benchmarking of Magician's performance, it became clear that there was no downside to coding OpenGL components directly in Java. And clearly there was a big upside to moving to a more Java-centric system. So, we proceeded to develop our own scene graph making heavy use of Magician for our OpenGL interactive display and picking.

At the time, Java 3D was in its infancy and we needed a more substantial scene graph to deal with the complexity of the 3D products we would exchange data with, such as Softimage and Alias|Wavefront Maya. Technically, Magician has been a rock. OpenGL is a fairly complicated API and our developers come from many years of 3D workstation hackery. We push the envelope of what OpenGL can do and the performance level of the graphics we use. Magician has stood up to the heat admirably.

Magician itself may not become the Java-OpenGL binding standard, but it is still quite possible that one will be developed. And I suspect that many graphics applications could still benefit from Java-OpenGL bindings in similar ways to SynaPix and other Java-OpenGL users alike.

1 2 Page 1
Page 1 of 2