Skip to main content

Tiger on the Desktop

Posted by chet on September 24, 2004 at 8:02 AM PDT

I know Tiger's getting a lot of press lately (after all, we don't ship
a new major Java release that often) and that there's a lot more about the
new release than the graphics end of things. In particular, with a platform
whose language changes so little and so infrequently, the types of changes
introduced in Tiger are pretty substantial and attention-grabbing.

But still, there were some features that we worked on in the desktop client
area of the platform for this release and if I can push! just
squeeze shove! my way through the teeming throng of Tiger
admirers, I'd like to mention a few of the highlights.

First, I should point out that on nearly every release, most of the work
we do on the desktop client goes into things that don't percolate up
into "features". This basically means fixing bugs, speeding things up,
supporting any new platforms,
and just making the existing platform run better every release.
We've heard, loud and clear, that stability is one of the top
requirements for our users, so the number one priority around here is
quality (and everything that goes along with it, including making
performance better and better, but not at the cost of core

Nonetheless, we do eventually get to work on new, cool stuff to enhance
the platform. It's that stuff that I'll be discussing today.


The main things on Swing's feature parade for Tiger were some new
Look & Feel features as well as table printing. I also have to
add here my favorite feature: JFrame.add().

  • Look & Feels

    There were two significant improvements in the Look & Feel area:
    Ocean and Synth.

    • Ocean

      The first was an update to the cross-platform look & feel. This one
      hasn't changed since the introduction of the Metal l&f. It had been
      a few years, that l&f was beginning to look a bit dated, so we worked
      on a more modern theme called "Ocean".

      One of the primary goals with Ocean was to Not Break Stuff. So now
      adjustments were made to the l&f which would have broken existing
      applications; the sizing of widgets is the same and everything should
      just work out of the box; it's just the skin of that l&f that's
      different (and, I think you'll agree, better).

      Users will get the Ocean l&f for free; an app that is run
      against 5.0 will pick up the Ocean l&f. Note that
      an app that subclasses Metal, or has other dependencies upon that
      look & feel, will still get the old Metal look & feel; again,
      backwards compatibility is the Prime Directive here.

    • Synth

      In addition to simply updating the cross-platform Java look & feel,
      the Swing team wanted to make it easier for developers to create
      newer, cooler look & feels for their applications. So they came
      up with synth, which is an architecture that makes it much easier
      to create new skins for applications, either through static XML
      definitions or programmatically through Java. I will leave the
      details of this approach to the experts; for more information on
      Synth, check out

      The Synth Look and Feel
      by Scott Violet on

  • JTable Printing

    Don't you hate it when you've got a great GUI with some awesome data
    in it and you can't output that data in any other place that the screen?
    The Swing team thought so too, so they made printing work with JTable.
    Enough said.

  • JFrame.add()

    The Swing team didn't call out this item when I asked them for their
    Tiger highlights, but it's probably my favorite Tiger feature in Swing
    and maybe the entire Java platform. Okay, so perhaps that's overstating
    it a bit. But I like it a lot in any case.

    Previously, you had to do the following to add a component to JFrame:

    	JFrame f = new JFrame();

    This is because of the Swing containment hierarchy; you cannot
    add a component to the JFrame itself, but only to the pane inside
    the JFrame which is tasked with being a container for sub-components.
    However, it was always awkward to have to remember that nuance
    and have to deal with Swing's containment hierarchy at this level.
    Well, they've fixed it. Now you can simply do this:

    	JFrame f = new JFrame();

    Internally, it's doing the same thing as before, only it's now
    handling the pesky containment details for you instead of your having
    to deal with it in your code.

Java 2D

Here are a few of the more significant features that you might notice about the
graphics engine in Tiger. For more information on 2D Tiger features, check out our Release Notes.

  • OpenGL

    This is an item that's not going to be apparent to most users right now,
    but should be an exciting thing for some developers and a taste of the
    great things to come, in terms of Java2D hardware accelerated graphics.

    We worked hard to enable nearly all Java2D functionality through
    hardware-accelerated OpenGL graphics on all Sun Java platforms (Solaris,
    Linux and Windows). This means we get accelerated graphics performance
    for such things as simple GUI operations (filling rects, drawing
    lines, copying buffers, caching and copying text glyphs as images,
    and so on), but we also get acceleration for way more interesting (and
    currently time-consuming) operations such as gradients, translucency,
    anti-aliased text, and transforms. This means that typical Swing
    applications work well, but more advanced 2D graphics apps just fly!

    There's a pretty big BUT here that I have to stick in at
    this point: this stuff all works extremely well ... except for the
    fact that OpenGL support on various platforms, graphics cards, and
    driver versions can be, er, less than optimal. Some of the problem
    lies with the way that we use the API and the types of features and
    performance we need; for example, we require different capabilities
    for Swing's back buffer than a typical GL app requires for its
    double-buffering operations. Some of the problem lies with the cards
    or drivers themselves; they simply have bugs that we tend to trigger
    (because we use the GL API in different ways than, say, Doom3 or
    other typical OpenGL applications).

    The net result is that we have an excellent implementation whose
    vast powers ... lie untapped by default. You can play with the
    OpenGL implementation by passing in a command-line argument to tell
    us to enable it:

    java -Dsun.java2d.opengl=true

    or you can set the same system property in your main()

    System.setProperty("sun.java2d.opengl", "true");

    But otherwise, our OpenGL acceleration is disabled by default.

    But don't fear; I wouldn't have bothered mentioning it if it weren't
    way cool. Not only does it provide excellent benefits in the right
    situations now, but it also provides the necessary building blocks for
    us to have this kind of acceleration enabled by default on future
    releases. So it only gets better from here...

    For more information on this OpenGL renderer, check out the information in
    The OpenGL section of our Release Notes

  • Managed Images Everywhere!

    We introduced the concept of Managed Images in jdk 1.4. Basically,
    if you happened to create your images in certain specific ways
    (including Toolkit.getImage(), Component.createImage(w, h),
    and GraphicsConfiguration.createCompatibleImage(w, h)) then
    we would try to create accelerated, cached versions of the images
    underneath from which we could then do hardware-accelerated image

    This system worked great for users of those particular APIs; developers
    didn't have to hassle with the management aspects of VolatileImage
    in order to enjoy the benefits of hardware accelerated image copies.

    But why the restrictions on which method calls you had to use?
    Why couldn't developers get the same benefit regardless of how the
    image was created?

    It was all a matter of just getting around to it. So in Tiger, we
    finally did.

    Now, you can create an image any way you like (including
    new BufferedImage(...)); if we can accelerate it, we will.

    Note that there are other things that can complicate the life and
    performance of a managed image; if this is a topic that interests
    you might check out these blogs on Images and
    this article on Intermediate Images for more details about image

  • Font Rearchitecture

    This is another "internal implementation" detail, but one which
    some users will definitely notice.

    The main work here was to take crufty old native code and move it up
    into elegant new Java code. This doesn't benefit the developers
    directly except that it makes the code much cleaner and easier to
    maintain (read: you'll get your bugs fixed faster and better).

    The real noticeable benefit of this change was that we removed
    threading constraints in the old code at the same time. Previously,
    much of the text processing was done in a synchronized fashion so that
    only one thread could access that key code at a time. This meant,
    for example, that an application rendering text to many different
    images at the same time would bottleneck in this code waiting for

    In Tiger, this constraint is removed and the font code is now
    Multithread Happy. Imagine the super-scalar servers that can now
    take advantage of all of those processors cranking away on text
    rendering simultaneously...

  • CUPS Printing Support

    For the Unix printing fans out there, we now have CUPS support!

  • ImageIO: plugins and performance

    We added a couple of key image format plugins in Tiger: BMP and
    WBMP (apparently popular image formats on some niche platforms;
    who knew?). We also worked on some major performance bottlenecks in
    image loading so the library is faster in some key areas.

  • Startup performance

    The platform overall enjoys some serious startup improvements
    in Tiger. Small
    parts of those improvements came in the graphics arena, in the way
    that we were loading and initializing things that could have been
    done faster (and now it is).

    There's still a ways to go toward Startup Performance Nirvana, but
    we're making progress.

  • Miscellaneous Performance Tweaks

    There were fixes in some rendering niches that are worth mentioning:

    • Primitive batching on Windows: we are smarter now about how we
      batch up line rendering calls when using our Direct3D renderer
      on Windows. This reduced the (significant) overhead per line
      and got us up to a 10x improvement in micro benchmarks (your mileage
      will vary; the biggest improvement will be seen when you issue all
      line calls together, not interspersed with other types of
      rendering operations).

    • Complex clip rendering speed was significantly improved in Tiger.

    • Footprint reduction for Toolkit images: We used to create intermediate
      images in our Toolkit image code which tended to bulk out the
      Java memory heap footprint. We've reduced much of that unnecessary
      garbage and got some pretty big footprint reductions as a result.
      Images tend to take up a pretty huge amount of memory (imagine: a buffer
      the size and depth of an average screen today takes about 5 megs
      of memory!), depending on the
      size and depth of the image, so saving the number of copies sitting
      around on the heap can help things out quite a bit.


There were lots of bug fixes in the AWT arena for 5.0. There were
also a couple of areas of major functionality work. For more
information on all of the AWT-related fixes and features in Tiger,
check out the

1.5 AWT Release Notes
Here's a quick take on some of the larger items implemented:

  • XAWT

    AWT was reimplemented on both Solaris and Linux to avoid being
    tied to the old Motif widget library system. The new XAWT toolkit
    was implemented using only Xlib, with a minimum of native code (and thus a minimum of native platform dependencies). XAWT is now the default
    on Linux, but Solaris still defaults to the Motif implementation
    for now. The default for either platform can be altered by use of the
    AWT_TOOLKIT environment variable or the -Dawt.toolkit command-line
    parameter; values for both can be set to either sun.awt.X11.XToolkit
    (for XAWT) or sun.awt.motif.MToolkit (for Motif). You can read more
    about XAWT at

  • X Drag and Drop

    Prior to Tiger, only Motif Drag and Drop (Motif DnD)
    protocol was supported on X11 platforms; now we also support the
    XDnD protocol. XDnD is a common feature on Linux and Java Desktop System platforms because of its support by GTK and Qt.


There were a few interesting (and huge) features added to our
internationalization offerings in Tiger. For more information
on these features than the blurbs below, check out
You can also get information on internationalization support in general at

  • Multilingual Fonts

    In the past, logical fonts were monolingual or maybe
    bilingual. This means, for example, if you were running in a Japanese
    environment, you could display Japanese and English text, but not
    Arabic or Chinese. To use a different language, you'd have to quit the
    application, change a few environment settings (the LANG environment
    variable on Unix or the language selection in the Regional Options
    control panel on Windows), then restart the application. This made life
    difficult, for example, if the application you were using was an IDE,
    and you were using it to develop software that was localized into
    multiple languages.

    With the multilingual font configurations in Tiger, all you have to do
    is install fonts for all the languages you care about on your system
    and the JRE will use them all together when rendering with logical
    fonts. Note that today's operating systems usually come with support for
    many languages on their installation CDs - all you have to do is ask for
    that support to be installed. The list of writing systems that
    the JRE will support when provided with the necessary fonts and
    input methods is at "">

  • Unicode 4.0 Support

    Character handling is now based on Unicode version 4.0 and there is also
    support for supplementary characters. For more information on
    supplementary character support, check out the article at

  • Big Things

    The DecimalFormat class now supports BigDecimal and

  • Vietnamese Support

    After a successful grass-roots campaign on the bug database (2517 votes
    on one of the bugs!), we have finally added support for Vietnamese in
    the java.util and java.text packages.

  • Native Unicode Usage on Windows

    We now use the Unicode features of the native platform on Windows, which
    means we can now handle text in some components without restrictions on
    Windows locale settings.

That's about it, or at least that's the most visible part of our
work on Tiger. We hope you enjoy it, and continue to send us feedback
on what else you'd like to see in the future.

Happy Hacking!

Related Topics >>