My number one wish for Java desktop for this year was cross-platform support for H.264 and FLV formats. Today has marked a first (and hopefully not last) step towards playing video content in Swing application – Java Media Components which is a part of JavaFX preview SDK.

Here is what you need to do to use JMC in your Swing application:

1. Download and install the JavaFX preview SDK. The rest of the steps assumes that the SDK has been installed in the C:|Program Files/JavaFX/javafx-sdk1.0pre1 folder.
2. Add the lib/jmc.jar to the classpath of your project.
3. Use one of the examples from the JavaOne presentation on JMC (see full code below).
4. Run the application with the following VM flag: -Djava.library.path=”C:/Program Files/JavaFX/javafx-sdk1.0pre1/lib”

I have tested the current JMC drop on the following formats:

• Flash content – FLV and SWF files. While the regular content plays correctly, i have not been able to interact with the content of an interactive SWF file.
• Container formats – AVI, MPG, MKV.

I have not been able to play the MOV files (H.264). Hopefully this will be addressed in the future releases of JMC, even before providing a cross-platform codec from On2.

Here is a sample screenshot of JMC playing an MKV file on a frame with translucent reflection (click to see the full size version):

MKV is a popular container format for video / audio content, and it is used by Azureus Vuze application. The screenshot above shows the trailer of “Watchmen” movie, and while Azureus uses the native executable for MPlayer to play these files, JMC goes a step further and exposes a Java API layer to Swing applications. You can find the full source code behind the screenshot at this location.

< Prev Next >

Three weeks ago the following RFE was filed in the bug tracker under Java2D team:

Windows Vista introduces the Consolas to replace the Courier font. The new font is a lot easier to read. The JDK should default to using Consolas instead of Courier under Windows Vista. Consolas is easier to read than Courier. Users will expect Java to look like other native applications which will switch over to Consolas over time.

After this RFE has been filed, it has been assigned a very low priority and closed as “will not fix”. The engineer responsible for this RFE found the time to list the reasons for doing so, and it is quite an interesting read:

This was considered in the JDK 6 development time frame. It isn’t just monospaced, there’s also serif and sansserif which arguably should map to Cambria and Segoe UI. There are several reasons why it wasn’t done.

1. Compatibility. Applications expect the JDK logical fonts to remain completely unchanged.
2. Quality. These ClearType fonts do not render particularly well except in “ClearType” mode. Many JDK applications expect the logical fonts to be ones that render well in all modes.
3. Fidelity with native apps is the role of the Windows Look and Feel. Using Consolas isn’t remotely sufficient to make the app look like a native app. The Swing Windows Look and Feel picks up this work, and it is hooked into the fonts used by native apps, and will use the appropriate fonts.

#1 and #2 are definite concerns. For #1 and we’d need to be comfortable with the potential for breaking some apps expectations, and for #2 we’d have to at least make cleartype mode the default for these fonts, whereas the long standing default is B&W. That change could also break some apps.

So for at least for now there are no plans to implement this.

While these points sound reasonable at a first glance, they do a great disservice to Swing applications running under core look-and-feels under Vista. Let’s look at the reasons why.

As a developer of a third-party look-and-feel library, i don’t feel too attached to applications running under the native-looking skins. There have been numerous discussions over the past years on relative merits of native vs cross-platform skins, and this post is not going to rehash the same arguments. However, i would like to concentrate on a very important aspect of UI usability – matching the desktop fonts and native font rasterization.

The major operating systems on the market today use different default desktop fonts. Windows XP uses Tahoma 11, Windows Vista uses Segoe UI 12, Mac OS X uses Lucida Grande 13 and Gnome uses DejaVu 10. An application that uses the same font under these platforms will look alien on all of them, even if other visuals (such as button backgrounds) match the native controls.

Karsten Lentzsch has pioneered the font lookup mechanism in the JGoodies Looks library, and Substance has extended it to additional platforms (Gnome, KDE and Mac). If you’re running your Swing application under Looks or Substance, you get the correct desktop fonts that match the current platform settings. Why is this important? Let me show you a sample Swing application running under Windows Vista with the native Windows look-and-feel:

Only the menus use the correct Segoe UI 12 font – all the other controls are using the Tahoma 11. Karsten has opened a bug in February 2008, and it still has no comments from Sun. This brings it back to the third point in the original bug report mentioned in the beginning – Windows look-and-feel is not using the correct font. How should it look like?

This is much better, and consistent with the native applications as far as the font selection goes. If you compare it with the previous screenshot, you will notice that since the font is one point larger, the entire UI needs more space. This relates to the first point in the original bug report – not breaking the existing applications. While a noble goal in theory, this cripples the applications that do want to have the correct visuals (no matter if the look-and-feel is native or not). On a related note, this is one of the bigger visual deficiencies of NetBeans running on Vista – the smaller Tahoma font makes it less visually appealing that it could have been.

Continuing with the first point in the original bug report and the expectations of mapping logical font names to physical fonts. Once again, while a noble goal in theory, it falls apart in practice. Here is a screenshot of the same application running under Windows Vista with Nimbus:

Nimbus is using the logical sansserif font for the controls, and it doesn’t map to Segoe UI. In addition, the default font size under Nimbus is one point bigger than the default desktop font size which makes all the fonts unnecessarily larger. Here is the same application running with Segoe UI 13 (just to show that sansserif doesn’t map to Segoe UI 13 – note the difference in letters e or s, for example):

And here is how the Nimbus looks when it’s running under Segoe UI 12:

There is one more point mentioned in the original bug report – the bundled font rasterizer that wasn’t too good in rendering the Segoe UI font. While this was true for both JDK 5.0 and JDK 6.0, the upcoming 6u10 addresses this issue by using the native text rasterizer on Windows (thus obsoleting the need for the pluggable SWT-based rasterizer that was available as a separate Substance plugin).

How important is this issue to Sun? I have submitted the question on using Segoe UI 12 in Windows look-and-feel in 6u10 to the last “Ask the Experts” session, but it was not addressed at all – let’s hope that my submission was lost on its way to the server. Java2D team has made a gigantic step forward by using the native text rasterizer on Windows in 6u10. All that needs to be done is to address bug 6669448 and reopen RFE 6723343.

Here are some Swing links that you might have missed during this week:

• Bruce Eckel wonders if anyone really cares about desktop Java, and the responses are mixed. Any established technology has its shortcomings, and it would be short-sighted to assume that the same question will not be asked in five-ten years about Flex. In the meantime, those have have invested in learning Swing produce good-looking and responsive applications.
• Karl Tauber has announced release 4.0 of the JFormDesigner tool for designing Swing user interfaces. New in this version are support for GroupLayout, FormLayout 1.2, improved conversion of IntelliJ forms and more.
• JavaPosse has talked about multi-threading in UI toolkits, and there’s a follow-up discussion on this subject in the Google group of the show.
• Eskil Blomfeldt reports that Qt Jambi AWT bridge has been rewritten to provide better support for window activation and whitespace around embedded components. It sounds that this project faces much the same issues as Albireo (that aims to provide the bridge between Swing and SWT). The Qt Jambi AWT bridge has still some unresolved issues with keyboard focus – something that has been addressed in Albireo.
• Alex Ruiz has announced the first beta for release 1.0 of FEST Swing, a library that provides a fluent interface for functional Swing UI testing.
• JavaSwing.net has a number of useful tutorials on using the JTextField and related classes, including the introduction to DocumentFilter to enforce upper limit on the number of characters, auto-conversion to upper case, number-only content and e-mail content. For more background on using regular expressions in e-mail verification see this article.
• Clemens Eisserer has committed the first changeset for the XRender pipeline under the OpenJDK innovators’ challenge program.
• And finally, Alexander Potochkin writes about the internal implementation of JXLayer‘s event interception on subcomponents in a non-intrusive manner using the InputContext class.