Posted by chet
on September 24, 2004 at 8:02 AM PDT
Brief takes on some of the cool features you'll get with the desktop technologies in Tiger.
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.
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.
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 javadesktop.org.
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.
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.
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 .
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:
or you can set the same system property in your
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
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
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
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.
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
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:
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
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
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
DecimalFormat class now supports BigDecimal and
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
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.