3D Graphics Programming in Java, Part 3: OpenGL

The Magician Java-OpenGL binding, front-runner in the cross-platform Java binding-for-OpenGL standardization race, recently has been withdrawn from the market. Read about other choices on the market, and about the respective strengths and weaknesses of Java-OpenGL and Java 3D. Also read about breaking news on jFree-D freeware, a new Java 3D implementation built on top of OpenGL.

Note: This article is based upon material originally published in the February 1998 issue of JavaWorld magazine (

It has been a while since our last installment in this series on 3D graphics programming in Java. Here's a quick refresher on what we were last discussing and where we left off. In the previous two articles (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 release of Magician or a standard 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 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 the 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.

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.


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 glibc

Sun JVM, Cambridge OpenGroup, RedHat Sun port, Kaffe

Mesa for all


Sun, Kaffe

Mesa for all


Sun, Kaffe

Solaris OpenGL, Mesa (respectively)



SGI OpenGL, Mesa


Sun, Microsoft, SuperCede, Borland JBuilder, Symantec Cafe, Netscape Navigator

SGI OpenGL, Microsoft OpenGL, Mesa

Mac OS

Apple MRJ, Metrowerks CodeWarrior

Conix OpenGL, Mesa






IBM 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




Unix (tested by developer on Linux) and Win32 (tested on Windows NT)


Unix (requires GNU make), and Win32


Interface to Mesa OpenGL-like library for Unix, Win32, other Mesa-supported platforms


A port of most OpenGL C functions to Java for platforms with OpenGL or Mesa implementations


Win32 (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.

Breaking news: jFree-D 0.1 released, Magician may yet live on
Just as many developers were beginning to wonder if Java 3D would ever be available on any platforms besides Win32 and Solaris, along comes Jean-Christophe Taveau's freeware release of an unofficial Java 3D port called jFree-D (see Resources for more information).

jFree-D promises several key advances to Java 3D technology:

  • Free availability of source code, allowing more developers to innovate around and within Java 3D
  • Runs under Java 1.1 development kits and runtimes. In contrast, Sun's Java 3D requires a Java 2 (JDK 1.2) implementation
  • Available on two of the most important development and graphics platforms not supported by Sun's Java 3D implementation: Linux and IRIX

Interestingly, jFree-D is implemented on top of the Jogl Java-OpenGL binding discussed in the sections above. Or rather, on top of Jogl 0.7 with some minor modifications that are made available from the jFree-D Web site as Jogl 0.7a.

In any event, jFree-D's layering on top of a Java-OpenGL binding highlights the point I have made several times previously, that OpenGL (and Java-OpenGL bindings) are a low-level sort of graphics API, while Java 3D is a high-level API. In jFree-D's case, the latter is built on top of the former.

It is also interesting to note that jFree-D's use of Java on top of OpenGL gives it the potential to be more portable than Sun's Java 3D. Indeed, jFree-D's requirements give it the potential to be compiled for just about any Unix or Windows environment (and probably a great many others too).

jFree-D's current release requires:

  • JDK 1.1.x
  • OpenGL implementation
  • C compiler
  • GNU make (available for all Unix flavors as well as Win32)

More detailed instructions on downloading and configuring the various pieces required to make jFree-D work is available on the jFree-D Web site (see Resources).

Though jFree-D is currently in early release, the availability of its source code makes it worthwhile for many 3D developers to investigate further. It's worth a look. In addition to jFree-D news, Arcane Technologies has announced in early May 1999 that they do intend to ship a new version of Magician afterall. The release will be 2.0 (instead of 1.2.0), and will contain features listed above for 1.2.0 minus Swing integration. Arcane has also promised to make a freeware version of Magician 2.0 available for certain types of use. Watch the Magician web site (in Resources) below for more information on this release.


This column completes a three-part series on 3D graphics in Java. We've seen how to create and manipulate Java 3D scene graphs and discussed some of the factors driving the decision between using Java 3D or a Java-to-OpenGL binding for 3D graphics from within Java. Along the way, we've used a variety of ready-made 3D content with loaders and we have shown you how to wed Web 3D and VRML to your graphics applications.

As you encounter Java 3D and Java-OpenGL questions, please visit the new Media Programming FAQ on my newly relocated Web site: I created this FAQ to archive interesting and frequently repeated questions pertaining to Java media programming. Most of these questions arise in response to my JavaWorld and Gamasutra articles, with a few thrown in from e-mail and elsewhere. I hope this FAQ will help developers leap some of the common Java media hurdles with a little more ease.

Don't be silent! This really is your forum to have your development issues addressed. Please let me know what you think, what your Java interests are, and how JavaWorld and I can help.

Bill Day is a technology evangelist for consumer and embedded technologies for Sun Microsystems. He is also an ACM Distinguished Lecturer. In addition to writing for JavaWorld, Bill plans to soon finish his book, Java Media Players, for O'Reilly & Associates. When Bill isn't evangelizing the Java cause, he loves to mountain bike, travel with his wife, and speak French. Java, c'est magnifique!

For Bill Day's previous Java 3D columns, see the JavaWorld Topical Index
/topicalindex/ jw-ti-media.html

Java-OpenGL bindings and jFree-D

OpenGL tutorial resources

The OpenGL Consortium resources

The Red Book programming reference

Arcane's Magician resources (while available)

Other OpenGL, Java 3D, and graphics resources

  • The OpenGL Perl Module site. Do you use Perl for Web hacking or other scripting tasks? If so, you might be interested to know that you can also use OpenGL from within Perl
  • Tom's Hardware Guide. Want more speed from your OpenGL applications? Upgrade your accelerator card! Tom Pabst has assembled an excellent section on video cards in general and good information on OpenGL accelerators in particular
  • "Fahrenheit: No Spontaneous Combustion Here!" Ron Fosner (Gamasutra, April 1998) Have you heard about a new graphics technology called Fahrenheit and wondered where it fits into the OpenGL versus Direct3D and 3D-graphics-in-Java puzzles? Read this third-party assessment for more information and an idea of how it will affect graphical application development in the coming year
  • "Exploring the Java 3D API," Travis Bryson (Performance Computing, April 1999) includes all the gory details of the API, and it includes an example application, EarthSim
  • SynaPix doesn't currently have a Web site. Keep an eye out in case it decides to publish one.

Latest Jobs

Sucker Punch Productions

Hybrid (Bellevue, WA, USA)
Senior Programmer

The Pyramid Watch

Game Designer (RTS/MOBA)

Sucker Punch Productions

Hybrid (Bellevue, WA, USA)
Senior Technical Combat Designer

Digital Extremes

Lead AI Programmer
More Jobs   


Explore the
Advertise with
Follow us

Game Developer Job Board

Game Developer


Explore the

Game Developer Job Board

Browse open positions across the game industry or recruit new talent for your studio

Advertise with

Game Developer

Engage game professionals and drive sales using an array of Game Developer media solutions to meet your objectives.

Learn More
Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more