Chris Campbell's Blog

Swing Archives

STR-Crazy: Improving the OpenGL-based Java 2D Pipeline

What was causing these crashes? If you're familiar with OpenGL, you probably know that it's important to do all your rendering from one (and only one) thread. While it is possible to render from other threads (if you're careful), OpenGL drivers are optimized for the single-threaded case. Games almost always play by these rules; they may use other threads for things like AI and physics calculations, but they do all their rendering from one display thread.

Well, we're not quite as lucky in Java 2D... Rendering requests can come from any number of threads (the EDT, a user thread, etc) even though we try to teach developers to avoid doing heavy rendering to hardware surfaces from many threads. In 5.0, we dealt with this by taking precautions, such as:

• ensuring only one thread is calling an OpenGL method at any given time
• using OpenGL rendering contexts only from the thread on which they were created

This makes OpenGL drivers reasonably happy, but it requires more labor on our part (meaning reduced performance), and despite all our efforts, drivers can still crash when there are many rendering threads in use by an application.

Clearly, something needed to be done if we ever wanted to see the OGL pipeline become reliable enough for day-to-day use by end users. For the past couple years, Chet and others on our team have discussed the idea of "single-threaded rendering" (STR), which would allow us to interact with native graphics libraries (such as OpenGL) from a single thread, thus making those libraries and drivers happy.

The idea originally came up as a possible solution to a number of threading problems we've dealt with in the past on the Windows side. But what better way to test these ideas than to implement them using the OGL pipeline? So that's what we set out to do in Mustang (JDK 6.0). Instead of this mess:

we'll now have the following, more elegant solution:

As you have probably noticed, I could go on and on about this project, but I'll spare you further pain. (If you really want more details, see this RFE.) The bottom line is that the project was a big success (from our perspective). The OGL pipeline is now more robust since we only interact with the native OpenGL libraries from a single "queue flushing" thread.

Going into this project, we were a bit unsure of the performance implications. We had our reservations, but surprisingly, there are some significant performance gains attributed to these changes, mostly because we can avoid going down through JNI on each and every rendering operation. Instead, rendering operations are buffered up on a NIO buffer, which is flushed periodically (or as necessary). Another benefit of STR is that it makes it much easier to "batch up" similar operations. OpenGL prefers to see lots of similar operations (like lines or rectangles) batched up within a glBegin()/glEnd() pair, so it is now easier for us to track which operations are being enqueued, and therefore easier for us to batch.

I'll save the detailed performance numbers for another day, but here are some quick numbers from my Linux configuration (JDS, 2x 2.6GHz P4, Nvidia GeForce FX 5600), but the numbers look similar on Solaris and Windows:

• SwingMark (internal Swing benchmark) is approximately 15% faster
• drawString() is about 250% faster (according to J2DBench)
• fillRect() and drawLine() are up to 2500% faster (according to J2DBench)
• with FireStarter (an internal demo), we can render about 2600 transformed/filtered/blended sprites per frame at 30 fps (as opposed to only 1600 sprites before STR)

(Note: these results are from microbenchmarks, so take them with a grain of salt...)

Now, why did I choose today to post this blog entry? If you said, "well, because the STR changes have just been integrated into Mustang build 27", give yourself a big pat on the back. It's true... The b27 snapshot was just posted on java.net today. Please download the binaries for your favorite platform and take an app or two for a test drive with the OGL pipeline enabled (-Dsun.java2d.opengl=True). Let me know how it goes... But first, a couple caveats...

Everytime I write about the OGL pipeline, the first question that is asked (without fail) is "Will the OGL pipeline be enabled by default?"... Well, the answer is still "no". It will never be enabled by default on the Windows platform (the DirectX-based pipelines are a better bet on Windows). However, I certainly hope that someday (Mustang? Dolphin?) the OGL pipeline will be enabled by default on Solaris and Linux, but only if we detect a "compatible" system, meaning hardware accelerated drivers are installed, bug-free, and performant.

Even with STR in place for the OGL pipeline, there are still just a few outstanding driver issues (more so with ATI's drivers than with Nvidia's) that prevent us from enabling the OGL pipeline by default. We've filed bugs with the respective companies, and we're still working with their driver teams to get the bugs fixed. I hope to post a follow-up soon to report progress on the remaining driver issues. For now, if you're using a video card from ATI, you may see some inverted colors and/or gradients being rendered incorrectly, and maybe even a crash on exit. These issues have been filed with ATI. If you're using a video card from Nvidia, you may see reduced performance when rendering software-based images on Windows, but otherwise, things should be looking pretty good.

If you're one of those people hoping to see hardware accelerated Java 2D on Solaris and Linux someday, please download the Mustang snapshots and continue to provide feedback on the OGL pipeline. The more feedback we get, the better the chances that we can enable the OGL pipeline by default in a future release.

Finally, A Micro-Benchmark For Java 2D...
A number of folks on the javagaming.org and JavaLobby forums have requested a way to benchmark Java 2D performance on various platforms and configurations. We've had an internal microbenchmarking application for quite some time called J2DBench that we use on a daily basis. In response to requests from developers, we wanted to make J2DBench available to the public, but it took quite a while to get permission from our lawyers to do so (you know how it goes).

Finally I'm happy to say that J2DBench is available as part of the JRL source bundle for Mustang build 27. To access the J2DBench sources, download the source bundle and cd to j2se/src/share/demo/java2d/J2DBench. In there, you'll find a README file, Ant build.xml file, and NetBeans 4.0 project file to get you started. In the future, we should be able to accept J2DBench fixes and improvements (e.g. new tests) through the JDK Collaboration (or similar) project on java.net... I'll blog with more details in the future once we figure out how best to handle that issue.

Thanks to Dmitri Trembovetski for taking the time to prepare the J2DBench source files for public consumption. I hope it will be useful for developers trying to performance tune their application, or as a convenient way to submit performance bugs to us on the Java 2D team. (For example, use the sample options file included with J2DBench to compare the performance of the OGL pipeline in JDK 5.0 with the improved pipeline in JDK 6.0-b27.) Good luck!

Our Work Is Never Done
Another improvement coming soon in a Mustang snapshot near you: a fix for the dreaded "gray rect" problem. This is one of Chet's favorite battles, so I'll let him describe the problem, and the solution, in an upcoming blog. However, I wanted to quickly mention that due to the way this fix was implemented, Swing is able to use BufferStrategy for their doublebuffering needs.

What makes this interesting is that it opens the door for the Swing backbuffer to be stored in the native OpenGL backbuffer, which is usually pre-allocated for us anyway, and often goes unused in the case of Swing applications. Making use of the OpenGL backbuffer means improved Swing performance (when the OGL pipeline is enabled), and also results in a big reduction in VRAM usage.

Prior to this change, the Swing backbuffer would be allocated in an OpenGL pbuffer. Pbuffers allow for hardware accelerated offscreen rendering, but they can be expensive in terms of VRAM footprint (they often use 12-20 bytes of VRAM per pixel!). So by eliminating the need for pbuffers for the Swing backbuffer, there will be plenty more VRAM available for accelerating things like icons and text. I'll provide more details about this change in a future blog entry.

There are plenty of other projects on my plate for Mustang, including:

• Fullscreen/DisplayMode changing on Linux (finally)
• OGL pipeline improvements (of course)
• Hardware acceleration for LCD-optimized text (important!)
• Wide line performance improvements (maybe)
• Applying STR techniques to our DirectX-based pipelines on Windows (Dolphin?)
• Other miscellanea (as always)

In my ears: Robert Pollard, "Speak Kindly Of Your Volunteer Fire Department"
In my eyes: Cao Xueqin, "The Story Of The Stone (Vol. 2)"

NetBeans 4.0: Perfect Enough for the Lazy and Demanding

NetBeans 4.0: My obviously-biased-but-still-relevant review
Okay, okay, put down your weapons. I'm not trying to start a religious war here. I confess: the title was a shameless attention-grabber (using the word "perfect" is always dangerous). There is no such thing as the perfect IDE, and there likely never will be. As long as software continues to evolve upward and outward, developers will demand new productivity enhancements from their IDE.

Give me a Java-level debugger, and next I'll ask for an integrated C/C++ debugger. Show me a plain Metal-based L&F, and I'll wonder why the developers didn't use a native L&F so that my IDE looks like it actually belongs on my desktop. Tell me about the powerful build engine, and I'll complain that it doesn't play well with Ant, the de facto standard in Java build engines. And why do I have to go outside my IDE just to use a testing harness or profiling tool? Where's my JDK 1.5 support? And on and on and on...

Apologies for the above (hypothetical) whining, but it demonstrates two characteristics that are universal among software developers: we're demanding (i.e. we spend a lot of time complaining, and we'll never be happy) and we're lazy (i.e. we don't want to use 17 different tools to accomplish one simple task). So what are the chances of finding a piece of software that satisfies my demanding taste and makes my life easier at the same time?

I'll admit, my requirements for an IDE are fairly atypical. Working on Java 2D, what I really need is an editor that can handle Java and C/C++ source files, and moreover a debugger that can seamlessly dive from Java into C/C++ code and back again. I'm certainly not in the majority of Java developers in that regard, so I can understand that no IDE meets all of my requirements. Regardless, I've downloaded major releases of NetBeans in the past in the hopes that some of my quiet demands would be met. Each time, I'd put it on the backburner because it just felt like it wasn't quite ready for prime-time. Sure, I could run NetBeans 3.6 on Mac OS X or Windows XP, and for the first time I felt like it actually fit in with the underlying windowing system. But that didn't really improve my productivity.

I downloaded a few of the development builds of NetBeans 4.0, and I must say that I was surprised. Sure, it was rough around the edges, but many of the little problems have been cleaned up for the recent 4.0 Beta release. I kicked the tires a bit by loading in one of my existing Ant-based projects (Mu). It quickly found all the targets from the build.xml file, so creating the deployment bundle was as simple as clicking "dist" in the list of targets. No need to struggle with importing all the various source files into a proprietary NetBeans project. Great! It just works!

Next I tried loading up another personal project of mine, Jaraoke (a karaoke app I wrote as an intern here at Sun almost five years ago; if I wasn't so lazy maybe I'd release the source code on java.net). The source code for that demo was fairly well-polished, but over time I grew unhappy with the names of some of the oft-used variables and classes, and I wanted to change the parameter lists of some of the methods. It would've taken hours to slog through the source code with emacs, trying to find all the instances of each variable and renaming them appropriately, or updating the parameter lists. Here was another good tire-kicking test for NetBeans 4.0... Just click the variable name you want to change and then click "Refactor". You supply the new name, and then NB does all the work for you, finding each use of that variable, and providing a selective list that you can easily review. When you're satisfied that everything looks right, NB will make all the necessary changes for you. What used to take hours now takes seconds. Rad! It just works!

So now I'm 2-for-2 with NetBeans 4.0, and there are plenty of other features I've yet to play around with:

• JDK 5.0 support (pretty important when you work on the JDK itself)
• Integrated JUnit testing
• Integrated profiler (coming soon)

While I can't say NetBeans 4.0 is the perfect IDE, I can at least say that it's a huge step in the right direction, and it should help make me more productive in the future. If you're demanding/lazy, take NetBeans 4.0 Beta for a spin. If you find any problems, do the NetBeans team a favor and submit your feedback now; it's the only way they can get one step closer to your idea of perfection.

What's new in Java 2D?
As usual we're working hard to improve Java 2D (and the whole client-side stack). Specifically, I've been investigating performance and quality issues with the OpenGL-based pipeline that is new in JDK 5.0. Most of the problems lie in the drivers themselves, so we're trying to be vigilant by contacting the driver manufacturers directly and making them aware of the problems. This should help improve driver quality and reduce annoying regressions so that we can start to enable the OpenGL-based pipeline by default on the platforms where it makes sense.

Right now I'm finishing up my work that enables true fullscreen and DisplayMode support on Linux/Solaris, something that developers have been demanding since we added the fullscreen APIs in JDK 1.4... The game developers out there should be happy with this change, which is targetted for the Mustang (6.0) release.

There are other perpetual projects that I'm involved with that should make life easier for those developing rich client (end-to-end) applications. And as always we're focussed on improving the end user experience: look-and-feel fidelity, high resolution display support, and graphics performance (we never stop) are all important areas that we're investigating for Mustang and Dolphin.

If you're interested in Java 2D, be sure to check out all of Chet's articles. They're packed with relevant technical information and they're a must-read if you've ever worked with images in Java 2D. (Hey look, Chet has a new picture on his blog page... Why does he look so confused?)

How To Be Good
Finally, I want to give a quick tip to all developers who give us feedback on J2SE... As always, we encourage developers to contact us for any issue they might have, whether it's a bug report, request for enhancement, or general feedback. We listen to all the feedback we get from places like JavaLobby and java.net, but we certainly appreciate it when developers use a constructive and friendly tone. I don't think I need to provide examples, but I can tell you we're more than happy to work with developers when they contact us politely. Here in the Java group at Sun, we're all just developers in the greater Java community; don't think of it as an "us-versus-them" situation... Okay, so bottom line, politeness counts.

In my ears: The Kinks, "Village Green Preservation Society"
In my eyes: Par Lagerkvist, "The Dwarf"

On Fat Cats and Fat Clients

Return To Hot Chicken (Noodle Soup)
I'm a bit under the weather this week, which is really quite unfortunate since said weather is amazingly springlike here in San Francisco. Illness seems to hamper my coding abilities, so I figure I'll take this time to catch up on my blogging.

Whatever Happened To Pong?
So what's new in the world of client side Java, you ask? The best place to start is the recent first-beta release of J2SE 1.5, codenamed "Tiger". (Tiger's a big release, and it's just about the only thing bigger than my 18 lb. kitty named Toledo.) I know plenty of people have blogged about all those new snazzy language features, but there's so much more, especially for rich client developers:

• a new OpenGL-based Java 2D pipeline (my little baby's all growns up, bringing all sorts of performance gains)
• new BMP and WBMP plugins for the Image I/O framework
• BufferedImage: now even better than butter!
• new and updated Swing look-and-feels (Ocean, GTK, Windows XP, Synth)
• a new X11-based toolkit (called XAWT) that reduces footprint and improves AWT performance on Solaris and Linux
• improved text rendering performance and many enhancements for international text
• support for CUPS printers on Solaris and Linux
• improved desktop integration for Java Web Start
• performance, ease-of-use, and stability improvements for Java Sound
• hundreds of other ease-of-use enhancements and bug fixes

Calvin Austin summarized these and many other new features in J2SE 1.5 in a Nutshell. You can also refer to the full list of enhancements for more details on individual features.

Black Math
I've heard through the proverbial grapevine that there have already been hundreds of thousands of downloads of the J2SE 1.5 SDK. That's a pretty big number, but we all know there are millions of Java developers. So if you do the math (don't forget to carry the one), you may come to the conclusion that there are still a number of developers who have not yet downloaded 1.5-beta!!

You! Yes, you behind the bikesheds! Run, don't walk, to java.sun.com and download the 1.5-beta SDK. Play with it. Love it. Be it. Try out the new language features (don't forget to use "-source 1.5"). Hammer on the new APIs. Make sure your existing apps are running better on 1.5... If you find a boo-boo, now is the time to report it! If you start testing your apps now on 1.5, there's a much better chance we can resolve your issues in the 1.5-beta2 or final release.

Don't Bring Me Down, Bruce
The year is 2004. The Java platform is maturing into a robust core of goodness. So why are rich client developers writing such low-level code? ... Tearing their hair out trying to connect a JDBC backend to a simple JTable? ... Agonizing over the best way to add an animation or video to a JPanel? ... Crying uncle when all they want to do is customize their L&F with some snazzy graphics techniques?

It's time we all move up in the world. I'm talking about higher level libraries for rich client developers. The reason developers are struggling is entirely our (meaning Sun's, and the community's) fault. Our bad. Fear not, however. We've been working on some exciting new projects that should make it much easier for Java developers to quickly whip up rich, media-friendly, networked, easily-deployable applications.

One part of this effort is called JDNC. Amy wrote a nice article last summer about this project. It's come a long way since then, and hopefully developers will be able to start playing around with these technologies in the not-so-distant future.

I recently came across this well-written article summarizing the author's "concerns" about the current state of rich client development in Java. I feel confident that many of his concerns will be addressed by the aforementioned projects. We'll be looking into ways to get the community involved in this effort, so stay tuned...

I've also blogged in the past about the various media API offerings from Sun. If we do our jobs properly, these libraries should play better together, and the API's should be more seamless. More to come.

In my ears: Frank Black, "Teenager of the Year"
In my eyes: Michael Chabon, "The Amazing Adventures of Kavalier and Clay"
In my mouth: Riiiiiicooooollaaaaaa

And This One Is Better Than Ever!

Do not expect any order or rhyme or reason for the content that follows. I've been away from the blogging game for several weeks, so I have a lot of random thoughts waiting to jump out of my dome (in typical fashion, none of them are well formed). Chet and Hans have been cranking out new blogs left and right, so I feel compelled to keep up with my end-of-the-hall-mates.

On the new OpenGL-based Java 2D pipeline: Work on this exciting new pipeline doth proceed apace. We've been making some excellent performance improvements over the past few days, and we're working with video board manufacturers to increase reliability, compatibility, and performance. I think desktop developers should be pleasantly surprised with the improvements offered by this pipeline, and I look forward to your feedback when 1.5 beta ships in a few months.

This new pipeline has been getting some publicity on various forums like Java Gaming and JavaLobby in recent weeks (check out those threads for some more detailed information; the JL thread was interesting until it devolved into a discussion on open sourcing Java, which seems to be par for the course). Now might be a good time to answer some frequently asked questions regarding the new OGL pipeline:

Q: You suck. Why isn't this pipeline being developed for Windows too (Sun is evil)? Why aren't you using a shared code base? Is it because you're dumb?
A: I'm rubber, you're glue... But seriously, we would very much like to offer this pipeline as an alternate implementation on Windows, but it won't make it in for 1.5... Hopefully we'll enable it in a future release, because it could really open some doors for interoperability with JOGL, and various other factors. The reality is that we have hundreds of video boards and driver combinations to support on Windows, and our effort is best concentrated right now on making our DirectX pipeline even more stable and performant. Driver flakiness is a big concern (just ask Chet and Dmitri!), so making sure that the OGL pipeline works on all Windows configurations will be a challenging task. We'd rather concentrate right now on making the OGL pipeline rock on Linux and Solaris, where graphics acceleration has traditionally been more dismal. (And yes, we do have a shared code base, with small platform-dependent modules to support GLX and WGL. It's a nice streamlined design, in my obviously biased opinion.)

Q: Why aren't you making use of UMD's Agile2D project? Is it because Sun sucks and hates open source software?
A: Agile2D is another interesting project out of UMD, but the downside is that it sits outside the guts of Java 2D and Swing, so you have to "port" your application to use Agile2D. Writing the OGL pipeline from the ground up allowed for much tighter integration with Java 2D internals, so you reap all sorts of benefits like using texture memory for caching glyphs and "managed images", in addition to all the performance gains reported by the Agile2D guys. If you tried out Agile2D, you should get all the same benefits and many more just by using core Java 2D and Swing in 1.5...

On the new "Sun Java Desktop System" branding strategy: Okay, so this one is taking a while to sink in, I'll admit. Some folks on JavaLobby are complaining that Java doesn't play a large enough role to warrant the name. Granted, a majority of the apps are not written in Java, but the biggies like Mozilla and StarOffice surely are Java-enabled. The important thing to keep in mind is that this is just the first release; prepare to see many more pure Java apps added to the package as time marches on.

I'm glad that the name doesn't mention the word Linux or Solaris... There's no reason for it. We're at an important cusp in the software world where the underlying OS has become irrelevant. Application developers and end-users alike no longer care what operating system they're using (yes, yes, gross generalization) as long as it runs their favorite cross-platform apps that help them get their job done, whether they are written in Java (NetBeans, Limewire) or not-Java (Mozilla, Evolution). If Sun decided tomorrow to base the Java Desktop System on OS/2 or FreeBSD or whatever, it wouldn't make a lick of difference to end-users (gross generalizations are fun). This general trend in the industry towards platform-agnosticism is really cool, and it's only going to accelerate.

On the state of the "Mu" project: I haven't had much time for Mu this summer, but that hasn't stopped others like Mr. Rob Ross from adding cool new features, like video playback. I made some minor enhancements to the "lite" client to improve ease-of-use (i.e. act more like iTunes), but those haven't yet been committed to CVS. Soon we'll be ripping out some of the internals and replacing them with an exciting new media content/metadata system about which I've been conversing with the Gas/JRec/Ptarmigan author. There's also talk about adding new pure Java codecs, live TV viewing, TV listings, and even some video conferencing functionality. Hopefully we'll make some more progress this autumn... Help from interested parties is always appreciated!

On Giants/A's playoff tickets: Should I stay or should I go? I could stay here and get some work done, or I could go sit in line at the ballpark with the rest of San Francisco. It's a beautiful day in the city, but I wonder if they have wireless down there? Better yet, I could bribe my sickly roommate into sitting outside all night for tickets. Yes, that sounds like a fantastic idea to me (hint hint nudge nudge)...

On Maven: I still haven't had a chance to play with Maven yet (beyond the few articles I've read), but it sure seems cool. Anything to eliminate the drudgery of build/doc/test systems is fine with me. And I used to think Ant was high-level...

On the genius of Bob Pollard: November 4th brings us a definitive box set from legendary lo-fi drunk-rockers Guided By Voices, entitled "Hardcore UFOs". Whenever I drop money on GbV, I come closer to understanding how crack addicts feel when they make their purchase -- 2% guilt and 98% elation. How can you not admire song titles like "I Invented The Moonwalk (And The Pencil Sharpener)"? The energetic, start-stop, repetitive-F-chord mania that is "Postal Blowfish"? The buzzing-guitar-string simplicity and effortless crooning of "Goldheart Mountaintop Queen Directory"?

On the virtues of vacationing (or "how to boost your debugging effectiveness"): This was a great summer. I took various long breaks (well, a few days at a time) away from work to visit with nature, friends, and family. My personal rule number one on these trips was "do not under any circumstances think about work", and then a funny thing happened. I'd be sweating my way up Half Dome or just plain sweating on a beach somewhere, and then I'd have a vision. No, it wasn't Yeti (what an odd assumption on your part)... It was the design flaw that's been nagging me for months, but this time it came with a solution. It's that old psychological notion of receiving inspiration when you least expect it. So there you go, next time you're working on some tough project, tell your boss you'll be taking a few days off to work-but-not-really on that important project.

On a related note, I was just reading James Gosling's latest blog entry about trusting (or better put, not trusting) yourself when debugging. I do this to myself all the time, and I never seem to learn my lesson. Just yesterday I was reading an old email I sent about the OGL pipeline, where I said something to the effect of "Q doesn't work even though I know that we're definitely doing Z, which should enable Q". So for months I built up this notion that the bug couldn't possibly be related to Z. And then what happens? I go revisit Z to discover a subtle flaw that had been there all along, and now of course when I fixed the bug in Z, Q is working just as I had always expected! Damnation! I could smite myself! (In fact, I just did that just to add a little drama...) Moral of the story? Don't trust yourself, but do listen to James, he's a smart guy.

On the coolness of iPods and iSights: I broke down and bought one of each, after hemming and hawing for months. The iSight is great, and the ease of iChat is unparalleled. Yet it just kills me that I'm able to video/voice chat with all of two people (Mac owners of course). So, good for Apple, they'll convince a couple more percent of the earth to buy their machines, and meanwhile everyone else (Windows/Linux users) is missing out on a fantastic hardware/software solution. Everytime a company ties people into a specific OS with some custom built application, the industry takes one step backwards. Argh like Charlie Brown.

I haven't yet received my iPod. I've been making all the necessary preparations, like converting my entire CD collection, encoded in the FLAC format, to MP3. I updated an old tagging/converting Java app that I had sitting around to handle the conversion, and it seems to be working like a charm. Yay Java. Note that by purchasing this iPod, I've admitted to myself that maybe the world isn't quite ready (yet!) for my idea of always-on, instant media transcoding/streaming from your home media server to your MIDP2-enabled cell/PDA (running a mobile version of Mu). But mark my words, this will be the future of personal, mobile entertainment! You just wait!

In my ears: The Super Friendz, "Love Energy" and Neil Young, "On The Beach"
In my eyes: Haruki Murakami, "The Wind-up Bird Chronicle"

Co-existence of Java 2D, Java3D, JOGL, and Mac-n-Cheese

[I was going to reply to Chris's excellent weblog in the talkback section, but I started rambling and it touched on some other thoughts I've had, so I decided to ramble here instead... Keep in mind that I'm only half-wearing my Sun cap right now (kind of like one of those green and brown, half A's, half Giants caps that were popular in the '89 Series), so I'm not speaking entirely on behalf of the company.]

In response to Chris Adamson's recent blog entry, The End (of Java3D) and the Beginning (of JOGL):

I'd just like to point out that JOGL is not an all-out replacement for Java3D. The two can co-exist, and one could potentially rewrite the platform-specific layer of J3D to sit atop JOGL. Java3D does indeed act as an "isolation layer" for the underlying platform when a developer uses its "immediate mode" APIs, but more importantly Java3D offers a high-level scene graph API. Many educational and corporate institutions have chosen Java3D because of its scene graph offerings, in addition to the appeal of its cross-platform nature.

On the other side of the coin you have the traditional game shops, who want to get as close to the graphics platforms/hardware as possible. Many of these folks are finding JOGL a better fit because it's a lower-level API, and they can make use of their existing OpenGL knowledge/code base. So I think it depends on the type of application you're developing which API best suits your needs. The gaming community has been clamoring for official Java bindings for OpenGL for quite some time, so that's where Sun's efforts seem to be heading, but don't count Java3D out for good; it still serves its purpose quite well as a higher level 3D graphics library.

Related to this discussion, we're also starting to see some folks on the javagaming.org forums asking whether JOGL would be a better fit than Java 2D for their apps/games. Again, JOGL is not the end-all and be-all Java graphics library. Many people don't realize that OpenGL is actually an expressive 2D library, despite its tight association with the 3D world. However, there's so much more to 2D graphics than rendering lines and sprites really fast (think medical imaging, complete support for any image format or color/sample model, printing, text rendering, stable offscreen rendering, etc). This is where Java 2D really blows the proverbial socks off all the other 2D libraries out there.

My answer to those folks on javagaming.org is the same as my J3D response: Java 2D is a higher-level, easier-to-use, more robust, more full-featured 2D rendering API than JOGL. Like J3D, the two technologies can play well together (if we do our job correctly, there should be no reason why the two API's couldn't be used in the same application). Also like J3D, we use hardware-accelerated graphics libraries (such as Direct3D and OpenGL) under the hood, so for many applications, performance should be virtually the same whether you use Java 2D or JOGL. As I mentioned earlier for J3D, we could also port our OpenGL-based Java 2D pipeline to sit atop JOGL (in fact, we're exploring this idea for a future release, which should further decrease our dependence on native C code). If you want to access the very latest in hardware technology, such as programmable shaders, or if you have large data sets of vertices and you're comfortable with the increased complexity of OpenGL, then JOGL would certainly be a better fit.

So the choice is yours... Each API has its benefits; it's up to you to evaluate which one is best-suited for your next project!

What's The Refresh Rate On Your Tongue?

As I was driving home tonight, I was listening to Forum on KQED (Michael Krasny rules! Oops, did I say that out loud?)... The topic of the show was advancements in assistive technologies for the blind. One of the guests was a blind man, the first to summit Mt. Everest. He has recently been participating in a research project that aims to convert visual signals into electrical impulses that can be detected by the tongue. Apparently, he wears a small camera on his head, and then the images it "sees" are processed in realtime and transmitted to a thin device that rests on his tongue. The signals are of sufficient resolution for his brain to interpret them (with plenty of practice) as if they were real visual stimulii. So far he's been able to "watch" his wife walk around a park, a ball rolling on the floor, and so on. Really changes the way you think about assistive technologies, eh?

Another guest mentioned a trend in designing accessibility into products from the start, rather than patching accessible features onto products as an afterthought. The example he provided was glucose monitors that retail in drug stores for $20 can cost upwards of $500 for a model that is accessible for the visually impaired. Manufacturers are beginning to realize that they can offset these costs by taking accessibility into account during the design phase, which generally results in a better product for everyone.

What's this mean for Java developers? Well, if you've ever written a Swing application, most likely your app will play quite nicely with assistive technologies, such as screen magnifiers and readers. That's one of the many perks of using Swing: you're automatically taking advantage of the Java Accessibility API. You can rest easy knowing that your application will be accessible by millions of users who would otherwise be locked out from your offering. You don't have to worry about whether a specific kind of assistive device is present; Java takes care of the gory details for you. One of these days, you may just find your application deployed to a tongue near you.

In my ears: Radiohead, "Hail To The Thief"

Psych Now, Good Times Later

I grew up in a small town in upstate New York called Red Hook. In that small town is our little old family cabin, known as "The Camp". That little cabin overlooks a small pond, and floating in the middle of that small pond this holiday weekend was a whole slew of old friends and family. And amongst the slew was a satisfied Java developer (and I'm not referring to myself). Go figure.

Let's refer to this developer as Jolene. After all, she's doing top-secret research at MERL (Mitsubishi Electric Research Labs) in Cambridge, and we wouldn't want to blow her cover. Anyway, as we floated in the lake and soaked up the sunburn, Jolene gave me a general description of the research she was working on at MERL. Cool stuff, but I was curious about the underlying technology. (Back at Georgia Tech, I found that most researchers were not fans of the Java platform, which pained me to no end, so I was wondering if that was the same everywhere.) Well, Jolene told me they were making heavy use of JMF, JAI, Java 2D, and plenty more. Although she couldn't delve into the details, she explained how each technology played a role in their project. She didn't have any complaints about these technologies, but she had concerns about deployment, so I described how Java WebStart might make her life easier. She was excited about the possibilities.

"Fantastic!", I thought. This was just the kind of customer interaction we (at Sun) wish we could have on a more frequent basis. And there we were, in the middle of nowhere, having this conversation. (Just then, a couple other friends realized we were talking about Java on vacation, and gave us a well-formed cannonball off the raft, effectively throwing water on the conversation. They were right, of course; beer, hot dogs, and lounging take precedent when you're on holiday.)

The point of the story, if there is one, is that we only hear about what our customers are working on (and what they think of our technologies) when things go wrong. All the little shops in my hometown proudly display all the letters of commendation they've received over the years. It's pretty rare that we receive such a letter at our offices at Sun. (When we do, they go straight to the hallway wall; it's kind of like putting a good report card on the refrigerator.)

This isn't surprising, though. It's great to have so many Java developers out there, keeping us on our toes, posting their concerns on JavaLobby, always motivating us to push the envelope with Java technologies. Wouldn't it be strange if Tom Tomorrow or Garry Trudeau all of a sudden penned a strip praising George W. Bush?

Okay, maybe that's a bad example. But I know for a fact that there are thousands of satisfied Java developers/users out there. We'd really like to hear from you... Everyone could use a little confidence boost every now and then, right? Send us mail and let us know how you're using our products, what you like about them, what you don't like... Or just say hello.

In my ears: Led Zeppelin, "How The West Was Won"

You Can't Do That With Java

[We had some difficulty setting up my blog account; this entry was actually written early last week...]

This is my first-ever blog. Yep, I'm selling out to the blog gods, even though I once said I would never blog. I even gave up writing in my own journal a couple years back once I realized that each entry sounded exactly like the last - a basic recap of the days events and nothing further. So if my blogging devolves into a similar style, I'll give it up. But for now, I think these weblogs give us a chance to have more "face time" with the community. Many developers have complained that Sun isn't open enough, and I'd really like to dispell that myth by offering some news and thoughts from the inside. Making Java better is a community effort, and we're just one small part of that community. Hopefully you'll come to understand that the folks in the Java Client Group really (really really) care deeply about the concerns of all our customers, and we all really want to see Java succeed everywhere.

Anyway, on with the program. I feel obliged to do the standard JavaOne recap... Let's just say that it was 400 times better than last year's JavaOne. This year, the mood was brighter, the products were cooler, and everyone I talked to was incredibly stoked about Java again (must be the new logo). The sessions all seemed to go well, and we had a lot of good interaction with folks at our booth and at the client group BOFs. On top of all that, we finally launched the javadesktop.org community site, which gave me a release vehicle for the project I've been hacking on recently, known quite unaffectionately as "Mu".

Possibly the greatest news we've had in a while was last week's announcement of the Game Technologies Group at Sun. I've had various lunchtime conversations with members of the new team, and believe me, this is one sharp group. Their charter is to find the deficiencies in the Java platform that prevent developers from writing leading edge games entirely in Java, and then plug those holes. One thing that really makes me cringe is when someone says, "You can't do that with Java". Well, have you seen "Alien Flux"? Did you see the High Dynamic Range OpenGL demos presented by Ken Russell and Chris Klein at JavaOne? With the GTG's release of open source Java bindings for OpenGL, OpenAL, and input controllers, I think you'll be hearing that "you can't do that" statement a lot less. [Ahh, I'm overcome with memories of a certain Canadian children's televsion program.]

Another complaint we've received in the past is that we have many great media technologies (Java 2D, Java 3D, JMF, JavaSound, JAI, Swing, and so on), but they don't work all that well together. It's great to know that we now have this team dedicated to making all these components fit together into one coherent layer. If all goes well, developers should no longer worry about mixing heavyweight components with lightweights, playing back video in a 3D application, or using the flexibility of Swing to create an interactive heads-up display in a 3D game.

Well, this first blog entry was all over the map, eh? Next time I'll pick one topic and stick to it like maple syrup.

In my ears: "Electric Version", The New Pornographers
In my eyes: "Blindness", Jose Saramago

This work is licensed under a Creative Commons License.