Ben Galbraith's Blog

Community: JavaDesktop Archives

Of Fonts and Java2D

The other day I googled for information on nice-looking fonts for Java2D and found nothing; this entry is largely to help future googlers.

A poorly-rendered typeface can really ruin my day. I'm passionate about creating beautiful software. Well, for the sake of those who've seen my code, I should clarify: beautiful user interfaces.

Generally, I'm satisfied that when my attempts fall short of my ideals, I'm the weak link in the process. After all, I control every pixel on the screen, so whether they look purty or not is my problem.

Except for the fonts. Ah, the fonts. Translating typefaces into pixels is a complex problem I'm all too happy to leave to others to solve. But of course, that's the double-edged sword; I'm stuck with other people's solutions, be they good, bad, or somewhere in-between.

I often find myself building user interfaces in Java Swing. Interestingly, Swing typically renders its own fonts--it doesn't rely on the underlying operating system. (Apple's JRE lets developers choose between having the OS or Java2D do the font rendering, but in the future, it appears this choice will go away in favor of Java2D). This could be a really good thing, if Java2D rendered better than the OS. Unfortunately, when compared to Windows and OS X, it doesn't. (It might render better than Linux, but I've never cared about that OS.)

This characteristic of Java GUIs is still arguably a good thing, because Java applications render consistently across differently platforms; consistently subpar rendering to many is better than inconsistent rendering behavior, which could lead to all kinds of problems when the bounds of strings are different on different operating systems.

The Problems with Java2D Fonts

I've been blabbing about how Java2D font rendering is worse than that of Windows and OS X. In what way is it worse? Back in 2004, I identified and documented what I judged to be the four most serious problems. I'll summarize these issues here:

1. Swing makes it difficult to use anti-aliasing. Back then, you had to either create your own UI delegates or subclass components. Nowadays, Swing either does the right thing and/or lets you configure global anti-aliasing with system properties.
2. Java2D mis-renders many glyphs. At the time, I listed these examples:
   • Arial 13pt (compare to Windows' 10pt rendering): x, S, X
   • Microsoft Sans Serif 11pt (Windows' 8pt): x, C, M, Q, 8, 9, )
   • Times New Roman 16pt (Windows' 12pt): 8
   • Tahoma 12pt (Windows' 9 pt): D
   • Tahoma 13pt (Windows' 10 pt): q
   • Tahoma 16pt (Windows' 12 pt): a, 0
   Here's one screenshot from the document that illustrates the problem:

   
   

   Today, I glanced at the same font in the image with Java 6 running on Windows XP today:

   

   We've come a ways: the 'S' looks great, but the 'x' and 'X' are probematic. That doesn't bother me too much, however, because of the next point.
3. Java2D lacks sub-pixel anti-aliasing. Well, not anymore. As Chet explained at length some time ago, Java2D now uses sub-pixel anti-aliasing when rendering fonts. The Arial 13pt example above now looks like this:

   

   How do you like them apples? In my experience, Java2D glyphs look really nice with the new sub-pixel anti-aliasing, and it makes Swing look really competitive with Windows XP font rendering with ClearType, as you can see:

   

   In the image above, Windows is on the top and Java2D is on the bottom. I prefer the weightier Windows rendering, but the Java2D rendering is nice.
4. Java2D needs higher-quality font rendering techniques, such as better glyph layout. Admittedly, this is a bit of a catch-all, but features like ligatures and properly spaced characters make a big difference in the quality of type. Unfortunately, I can't see that this has gotten much better.

A Problem of Spacing

To get a feel for the problem of spacing, check out how both OS X and Java2D (Java 1.6, Windows XP) rendering the same text with Lucida Grande Bold (11 points, Java2D text attributes set to PLAIN):

It's pretty amazing how gorgeous OS X's rendering of the text is; it's as though a magazine climbed into my LCD. The Java rendering looks pretty rough, due to both the glyph quality and their spacing. Check out the difference in character spacing in the word "quick" versus the word "brown" or how the "ps" in "jumps" is floating a bit too far to the right; also, note how Java renders the 'e', 'q', and 'w' compared to the Mac. It's pretty hard to argue that one could prefer the Java rendering, though the increased intensity of the pure white hue is a potential benefit.

Am I Crazy?

I know there are a large swath of folks who are just happy if they can get their app to do something and view my rambling on about fonts as silliness. I have no problem with such.

My point here is that when you want to create gorgeous applications, these things really do matter, and they matter quite a bit. If you disagree with this assertion, well, we'll just have to disagree. (I'm reminded of a recent Wall Street Journal column by Lee Gomes in which he said audiophiles are divided into two camps: the crazy and the totally insane.)

What To Do?

I've had the opportunity to meet Phil Race, the font guru on the Java2D team, and I'm satisfied that he's smarter than I'll ever be, that he knows about these problems, and that he'd fix them if Sun's priorities and resources permitted such to happen. And who knows but that such fixes are already in the pipeline? (Well, I guess Phil knows.)

That doesn't relate to my problem: I've got an app that I need to make gorgeous today. So, what do I do? I don't have time to render fonts myself. That's Hard Stuff. But, I could lay out the individual glyphs myself and do a better job than the Sun folks. But, having met Phil, I assume if that problem were non-trivial, he'd have improved it himself by now. However, by only caring how fonts look in my applications, as opposed to the entire world's set of Swing apps, perhaps I can get some results in this area.

Finding the Best Fonts for Java2D

In a past life, I did lay out glyphs myself, but that code no longer belongs to me, and I'm not in the mood to write it again. So the easiest solution is simply to check how Java2D renders fonts at different sizes and see which ones look best. I created a simple program and rendered some test output for Java2D using sub-pixel anti-aliasing (HRGB) with all of the fonts available to the JRE in a default Windows XP installation (along with Lucida Grande Bold), split into three large images.

My favorites are:

• Arial 11pt Plain (12 and 13 ain't bad either):

  

• Franklin Gothic Medium 9pt Plain--what an attractive small typeface! 10 and 11 are pretty good as well:

  

• Georgia 9pt Plain, a seriffed answer to Franklin Gothic's clarity (10-13 are also really nice):

  

• Lucida Sans Regular 12pt Plain (11 is also nice):

  

• Microsoft Sans Serif 12pt Plain

  

• Segoe UI 11pt Plain

  

• Verdana 9pt and 11pt Plain

  

Your Favorites?

I was surprised at just how good some of these fonts look. Thanks Phil! Did I miss some other good ones? Are there other fonts that you've used with good results in Java2D? What are your "go to" fonts for beautiful type at large sizes?

Update: Whoops. I put together this blog entry in a bit of a hurry whilst flying from Point A to Point B and I included some faulty images (due to a bug I introduced in the program I wrote to display the fonts; the last 2/3 of the fonts weren't sub-pixel AA'd):

1. The comparison between Lucida Grande Bold Java2D vs. OS X originally showed the Java2D rendering without sub-pixel AA; this was a mistake. I updated it with a sub-pixel AA version, as shown above. Note that the observations about subpar glyph formations and layout still remain valid (as I originally noticed them with properly sub-pixel anti-aliases imagery).
2. Two of the three large images I linked to were not sub-pixel anti-aliases as claimed. This has been fixed.
3. Six of the seven fonts displayed at the end of the blog entry were not sub-pixel anti-aliased; this has been fixed.

The observations that drove me to write this blog entry were with properly sub-pixel anti-aliased type; so the content stands. Sorry for the goof-up.

Java on Leopard: The New Rendering Pipeline

In my recent duo of "Whiners! No whining!" blog posts, I made a statement with which some commenters have taken issue:

the already-mentioned transition to Sun's rendering pipeline (a tough but correct decision reflecting a commitment to cross-platform fidelity)

Specifically, Michael Urban wrote in to say:

I really don't see how this has anything to do with cross-platform fidelity. After all, Sun JVMs don't even use the Sun pipeline by default anymore. They use the OpenGL pipeline where / when it is available. I think all Apple really did by switching to the Sun pipeline is make Java2D performance unusably slow, and create tons of support headaches for developers who now have to field all the complaints from their customers about why their application no long works correctly on Leopard, and either explain to the customer who to enable the Quartz pipeline, or ship a patch for their application to re-enable the Quartz pipeline.

Michael, as you'll see below, Sun's OpenGL renderer is indeed part of the pipeline Apple is now using. And unless I'm really out of date, I think the traditional GDI platform is still used on the majority of Windows JRE installs.

And "opinali" opined:

but what you said about the transition to the Sun rendering pipeline being an improvement, that was pure spin that I'd only parse as radical Mac zealotry. There is NO justification for this (except Apple having no resources / time / priority to update the accelerated pipeline for the new OS). It's the opposite direction that everybody else is moving; see for example Java 6 UpdateN, which will move to the new D3D-accelerated pipeline by default on Windows. The Java platform must keep up with the LAF improvements of the latest OSs, like Vista and OSX, which are severely raising the bar in sfx (remarkably with WPF, Quartz, Beryl etc) so the Java toolkits (AWT/Swing/J2D) can't reasonably compete without full acceleration. And also, Java must support the development of "filthy rich" clients, not that I like this trend, but many users do so developers should be able to crank out sophisticated J2D effects that don't bring Java's performance to its knees. These requirements are MUCH more important than "pixel-by-pixel portability" (and for this, there's always the option of the portable Java LAF).

Well, look. Dissent on this topic is perfectly reasonable; there are trade-offs at work. But, I'm confident that in the final analysis, most folks will agree this was the right decision.

Let's start with precedent. Initially, Sun relied on the underlying platforms to perform font rendering, but in Java 1.2 a new Java2D-based pipeline was introduced. This pipeline has represented a substantial engineering investment, especially as Adobe font support and subpixel anti-aliasing have come into the picture. Why not just use the underlying platform's font renderer?

The answer, of course, is that it would be nearly impossible to write cross-platform applications that do any detailed layout or typography work without Java itself handling the rendering. Sun abandoned the technically superior rendering approach in most situations in the name of compatibility.

Now, with Quartz, we see shades of the same issue. Quartz is great, Quartz makes certain drawing operations wicked fast in Java, but Quartz is much different than Sun's pipeline. The canonical example of just how different is the fact that aliased lines require Apple's adapter to draw an anti-aliased line (the *only* kind of line in Quartz) and then mask out the aliased pixels. Try some benchmarks to see just how slow this is.

Anyone who has written a rendering-heavy app has run into the pain that these differences cause. Any time the cross platform abstraction breaks and you need to adapt for the underlying platform, Java loses (or, phrased less dramatically, the value proposition of Java leaks in direct proportion to how often its abstractions leak).

Now that Sun has produced an OpenGL pipeline and is committed to making it work, why wouldn't Apple drop their own Java bridge to a Cocoa bridge to OpenGL in favor of Sun's OpenGL pipeline? Sun now pays the tax to make OpenGL behave the same as their traditional GDI (and Linux and Solaris equivalent) pipelines.

Thus, the Apple team no longer duplicates work that Sun is doing and they can spend more time on other features (like porting the new applet architecture to OS X, for example).

There are really only two sets of potential losers here: those who use Java to develop for OS X and don't care about other platforms, and those who need a fully tested and optimized Sun rendering pipeline today.

For the former, I'm convinced it's not a big deal. If you really want to take advantage of OS X goodies, learn Ruby and use the Ruby/Cocoa bridge. If you're content to just look like a native OS X app and don't need really fancy effects, the new Aqua look-and-feel is quite nice and I'm hopeful it will evolve favorably over time.

For the latter group--that need it today--I think you're confusing needs and wants. Use Quartz today and switch to the Sun pipeline when you're ready. In my own testing, it works quite well for most needs.

Am I wrong? Was this move a blunder? I'm curious to hear other points of view.

UPDATE: amasson pointed out that the Quartz stack includes a non-retained mode drawing API. I excised the relevant paragraph. See comments below for details. Thanks amasson!

More on Leopard's Java 1.5: The Release Notes Michael Urban Should Have Read

I recently blogged about the recent Mac whining from the Java community. Subsequently, I browsed through OS X 10.5 Leopard's Java release notes. Wow!

I think most people have by now realized that Michael Urban's straw-that-broke-the-camel's-back example of how Apple has regressed Java 5 is actually a step forward (i.e., the Aqua look-and-feel uses the *right* icon in message boxes now), but it gets much better.

Some of my favorites include:

• "It is now possible to create a circular indeterminate progress indicator from a JProgressBar in Swing. Setting the "JProgressBar.style" client property to "circular" will create a small round indicator when the progress bar has been setIndeterminate(true). Please see tech note TN2196 "New Control Styles available within J2SE 5.0 on Mac OS X 10.5" for more information."
• "Horizontal scroll events are now delivered to JScrollPanes as Shift+ScrollWheel events, since there is no horizontal scrolling API in Java. Horizontal scrolling mouse events will now move the content view horizontally, along with Shift key modifier events."
• "There has been no way to specify smaller versions of the default Mac OS X Aqua controls. Many JComponents now change their default size, appearance, and font when the "JComponent.sizeVariant" client property is set to "small" or "mini". Please see the tech note "New Control Styles available within J2SE 5.0 on Mac OS X 10.5" for more information."
• "JTextFields can now be converted into search files using the "TextField.variant" client property set to "search". Please see the tech note "New Control Styles available within J2SE 5.0 on Mac OS X 10.5" for more information and additional options to configure JTextField based search fields."
• Apple introduced a 64-bit JVM with Leopard along-side the 32-bit JVM.

And, as anyone who has spent any time playing with the JRE will have noticed, the release notes omit many smaller features related to polish in their ground-up rewrite of the Aqua look-and-feel.

There will always be the whiners about Java 1.next; Apple is Apple. As the snake says in the proverbial parable, "you knew what [Apple] was when you [bought your MacBook Pro]." Whine about this to someone who cares.

But those who complain that Apple has lessened their support for Java at a time when Apple has done more to make Java a first-class peer of Cocoa and other dev environments--you could not be more misinformed.

UPDATE: I posted follow-up comments on the new rendering pipeline in a new blog entry.

The (Java on OS X) Sky is Falling!

With a tip of the hat to Casablanca, I'm shocked--SHOCKED--to read the really rather embarrassing blog entries from folks in the community about the state of Java in Apple's latest OS release (see David Herron's blog for a round up of some).

Please.

It turns out that Swing in Leopard represents a huge leap forward in Apple's commitment to desktop Java. Among the new goodies I've stumbled across are animated triangles in JTrees, the already-mentioned transition to Sun's rendering pipeline (a tough but correct decision reflecting a commitment to cross-platform fidelity), a revised UI for JTabbedPane, improved button rendering behavior, and more.

I suspect as time passes, more improvements will come out and folks will understand just how busy the Apple Java team has been.

So, what, there are some bugs in OS X 10.5.0? They didn't have 1.6 ready out-of-the-chutes? Big deal. Give it time, just like we have with every release of Java since OS X first shipped with Java 1.3. Only now, thanks to Parallels/Fusion, we actually have a great alternative for the impatient.

Kudos, Apple, for a fine release and for all your hard work.

UPDATE: I've elaborated a bit after reading the release notes.

Desktop Matters Blogging

I'm blogging about Desktop Matters over at my personal blog. Some of the interesting news so far is that JIDE is open-sourcing 1/3 of their code, a new cross-platform look-and-feel designed by Sun called Nimbus, and more...

Open Party During Desktop Matters

Hard to believe that Desktop Matters is finally upon us. I'm very much looking forward to hearing all the talks and being with some folks from the Java Desktop community at the show.

Recognizing that not everyone who might wish to attend the conference is able to come, we've decided to open up the party Thursday night to everyone who wants to come. We also posted an invite on Ajaxian.com, so perhaps quite a crowd of folks will come (then again, perhaps not).

So if you're in the neighborhood, why not drop in and say hello? There will be food and drinks, but not sure how long they'll last.

Party starts at 8:00 pm, located at the Wyndham San Jose (map here). The room is Salon H (at the mezzanine level).

I Love Intelligent Tools...

I’m writing some Java2D code, and I notice that IDEA (my code editor) highlighted parts of my code:

Check out the caption at the bottom of the window. It turns out (as any good Java2D programmer knows) I’m reversing the width and height arguments — but how did IDEA know? Whether its lexical analysis or a special case built into the tool, wow! This kind of stuff is infinitely useful.

(cross-posted on Married... with Children, my personal blog)

Desktop Matters Agenda Updated

Continuing my series of updates on Desktop Matters, I'm happy to say we've given the agenda much more shape since my last posting. The show continues to be one track, but we've expanded out a touch to one and a half days.

Check it out and let me know what you think!

Desktop Matters Open for Registration

We've got the final dates locked in for Desktop Matters: March 8-9 in at the Wyndham in San Jose, California. The conference website is live, as is the registration link.

A big "Thank You" to all of you who offered to present at the show; we'll be finalizing the agenda in the coming weeks and getting in touch with you.

Desktop Matters is still technically a one-day show, but we're also putting on a "pre-show" event in the hotel where, among other things, you can bring your Swing questions and apps in person and discuss your ideas / problems / etc. with some of the speakers and Swing experts at the show.

We're also really struggling with a possible decision to go to two tracks; we've got a lot of content and one day isn't a very long time... anyone with opinions on the issue, please comment here.

Thanks!

The Desktop Matters

With the advent of Ajax, it's been fun to watch the Web in a renaissance as technologies we dismissed years ago have come into vogue. There's such buzz in that space that some are beginning to predict that web applications will replace desktop apps entirely and that perhaps even a "Web OS" concept will take root.

Maybe the future is in Web browsers. But I'm pretty satisfied that for years to come, desktop applications will continue to play an important role in the software ecosystem. In short, the desktop matters.

In this vein, we're happy to announce Desktop Matters, a desktop-focused conference to take place in February 2007 in the Bay Area, California (probably Feb. 23 somewhere close to Santa Clara). My Ajaxian partner-in-crime, Dion Almaer, will be co-producing and co-hosting the event with me, and Jay Zimmerman of the No Fluff Just Stuff conference series will handling the heavy-lifting and lending his conference expertise to the event.

We had considered making an event for all desktop technologies across all platforms. That vision may eventually come to pass, but this first Desktop Matters event will be focused on Java Desktop technologies.

While our recent Ajax Experience conference had sixty sessions across six tracks over three days, the Desktop Matters will be a one day / one track event. It's not that we couldn't find enough content to fill up a bunch more slots, but we felt that the Java Desktop community is a pretty tight-knit crowd and it would be more fun to throw everyone in the same room.

Sun's Swing team has graciously offered to participate; Scott, Hans, Chet, Richard, and former-intern-extraordinaire Romain Guy will be there presenting.

The attendance fee will is still being worked out, but it will obviously be far lower than the typical $1,500 range for multi-day, multi-track events. We're trying to make it as accessible as possible.

The agenda is still being finalized, but it will include topics such as how to be more productive with Swing, how to make Swing look amazing, and sessions on third-party Swing libraries and tools. We may even have some non-Java folks present, just to show us how things are done on other platforms -- but that part of the show isn't finalized yet and may not happen. The show will wrap up with a party / networking event, while Chet doing stand-up comedy at some point (he doesn't know this yet, but we're confident after a few drinks we'll get him on stage).

Speaking of the agenda, would you like to present a session at the show? What with it only being one day, presentation space is very limited, but if you have an interested in presenting or simply being a part of the show in some way, please let me know (send email to desktopmatters@galbraiths.org).

I'll follow up with a commitment on the date, the venue, and the price a little later this week or earlier next. In the meantime, I hope you'll clear a space on your calendar and join us!

JavaBeans, Binding, and AOP

My friend Richard Bair recently told the world that the colloquial definition of JavaBeans as an object with getters and setters is incomplete, and demonstrated how a handy base class can make adding PropertyChangeListener support easier.

I'd like to pick up where his discussion left off. Over the past few years, I've been pondering how to make it easier to develop Swing applications. One area of pain in Swing is binding; that is, copying values from Swing widgets to business objects and vice-versa.

Swing components, as Richard mentioned, are observable via PropertyChangeListeners and other types of listeners, so detecting when widget values are changed and copying those values to objects as a result is pretty easy (though there are a few subtleties to get right). The reverse, however, is not free. In order to detect when values in an object have changed, one needs to use some mechanism like the JavaBean spec to introduce observability into JavaBeans.

And for me, therein lies the rub. Firstly, I hate repeating myself, and writing firePropertyChange("property", old, new) over and over again seems a big pain. Second, the string literal gives me the heeby-jeebies. If I'm going to all the bother of using a strongly-typed language, I hate having the bugs of loose-typing introduced with none of the benefit. Third, what if I'm using some pre-constructed business objects that aren't observable and can't easily be made to be observable?

(A quick tangent: Everyone ought to know that walking stacktraces is one of the most expensive VM operations around. Yet, just for fun, I created a version of firePropertyChange(...) that automatically obtains the property name by walking the stacktrace. Here it is:

    protected void firePropertyChange(Object oldValue, Object newValue) {

        try {

            throw new Exception("stacktrace");

        } catch (Exception e) {

            StackTraceElement[] st = e.getStackTrace();

            String property = ReflectionUtils.getPropertyFromAccessor(st[1].getMethodName());

            firePropertyChange(property, oldValue, newValue);

        }

    }

Never use this code in a tight loop.)

For all these reasons, the binding solution I use takes a hybrid approach. To save myself a lot of explanation, let me just say that when the Swing widget's value is changed, the framework can copy the value to the business object automatically, but the framework does not copy the value back to the Swing widget until the developer specifically requests that the value be copied from the business object back to the Swing widget.

In practice, it looks something like this:

    binder.defineBinding(businessObject, swingWidget, "fieldName");

    // at some future point, call this next line to update the UI from the object

    binder.updateWidgets();

I've used variations on this technique for a while now, and it works very well. When combined with a container-managed form system, it actually works nearly as well as true bi-directional binding as the form lifecycle can introduce automatic calls to binder.updateWidgets() at various flow points (and the automatic behavior can of course be disabled).

But I've been aware for a long time what the real solution to this problem is: Aspect-Oriented Programming (AOP). Using AOP, you can easily add PropertyChangeListener support to any object, even those for which you don't have source code, and generally solve all three of the problems I have with manually adding PropertyChangeListener support.

Unfortunately, I don't use an IDE that has AOP support, so I haven't been able to explore AOP much up to now. But the latest release of my favorite AOP framework, AspectJ 5, enables a new type of AOP syntax based on Java 5 annotations (called @AspectJ).

Using @AspectJ, I can create a simple class that handles all of this property firing for me:

    @Aspect

    public class JavaBeanObservabilityAspect {

        @Around("execution(* *.set*(..))")

        public void timeElapsed(ProceedingJoinPoint jp) throws Throwable {

            if (jp.getTarget() instanceof JavaBean) {   // only fire listener if a JavaBean

                JavaBean o = (JavaBean) jp.getTarget();

                String property = ReflectionUtils.getPropertyFromAccessor(jp.getSignature().getName());

                Object oldValue = ReflectionUtils.invokeAccessor(o, property));

    

                // proceed with the invocation of the method

                jp.proceed();

    

                Object newValue = jp.getArgs()[0];

                o.firePropertyChange(property, oldValue, newValue);

            } else {

                // if not a bean, just proceed with the invocation normally

                jp.proceed();

            }

        }

    }

The above is a crude beginners example of how to automatically fire the event on all JavaBeans -- a more refined example would show you how to actually add PropertyChangeListener support dynamically to any object. The example I gave is also problematic in that if the setter already fired the event, it would be fired again by the aspect. And, I coded this version here in my blog, so if it doesn't compile, don't sue me. But... you get the idea.

The beauty of @AspectJ is that because it just uses normal Java 5 annotations, you can use your IDE to create and compile the aspects like any other part of your code base. To actually use the aspects at run-time, you must weave the aspect into your code.

Weaving is the process of augmenting Java classes with the additional instructions defined by one or more aspects (such as the one above). You do that with a special compiler that comes with Ant tasks that can be easily introduced into your build process.

But for the impatient, there's this cool new thing in ApsectJ 5 called load-time weaving ("LTW"). With LTW, you pass your JVMTI compliant (Java 1.4+) VM a property that configures an agent that can weave your classes as they are loaded:

    -javaagent:aspectj/aspectjweaver.jar

You then create an XML file (META-INF/aop.xml) that specifies with aspects to weave, and into which classes, such as:

    <aspectj>

        <aspects>

            <aspect name="org.galbraiths.beans.JavaBeanObservabilityAspect"/>

        </aspects>

    

        <weaver options="-verbose -showWeaveInfo">

            <include within="org.galbraiths.beans.JavaBean"/>

        </weaver>

    </aspectj>

And presto! You've got AOP in your project (along with a handy speed hit whenever the affected classes are loaded for the first time). There are all kinds of fun things to do with AOP, such as introducing ultra-low-intrusion microprofiling, verifying proper Swing threading, and so forth. Blogs for other days.

So -- for the purposes of binding, you may not need observability in your objects, but if you do want it, consider AOP for adding observability without repeating yourself all over your codebase -- and for adding it to code you don't control.

If the pretty good AspectJ project documentation doesn't do it for you, check out AspectJ in Action, written by Ramnivas Laddad -- a friend and collegue whom I greatly respect. His book doesn't cover @AspectJ, but is widely considered the best AspectJ book around.

As with most of my entries, this was cross-posted on my personal blog, Married... with Children

A Desktop Application Developer's Conference?

(cross-posted on Married... with children)

I've already talked about the Ajax conference that we over at Ajaxian.com are producing (May 10-12 in San Francisco; won't you join us?). As I contemplate the great fun that we'll have at that event, I've started thinking of my other love: desktop application development.

I spend the vast majority of my time developing Swing applications. I am more interested in desktop app development than pretty much any other programming discipline. As I work with other desktop application developers, I'm seeing a lot of gaps in our collective knowledge. Too many of us really don't understand good UI design principles. Often, we haven't taken the time to check out what our (WinForms, Cocoa, SWT, etc.) neighbors are up to. And, of course, wouldn't it be nice to learn more from others about how to use our toolkit of choice more effectively?

Do you think it would be a good idea to hold a 1-2 day Desktop Application Development conference? I'm thinking such an event should have at least a 50% focus on user interface design issues (i.e., interaction design) with the other bit being about how to get the bits to actually do the interaction. I'm also wondering if it wouldn't be a good idea to invite all desktop application development disciplines to speak and attend. I for one would be fascinated to hear talks from various foreign GUI toolkits about how their stuff works and what they're up to.

Should it be a small, boutique, no-frills conference focused on intermediate/experts, or a larger, more general-interesting conference with a lot of introductory-level material? Should it have a Java-only focus, or is inviting the entire community interesting to you?

What do y'all think? Would holding such an event in the fall or winter of this year / early next year be a good idea?

International "Focus Abuse Awareness" Month

(Cross-posted on Married... with Children)

I am so sick of badly behaved focus behavior! I hate it when websites have onload handlers that do janky things with the focus, moving it to some arbitrary form field, not realizing that many users start interacting before the page is completely loaded. I hate it when desktop applications steal the focus, causing whatever I've been typing in some other appication to be lost.

Please, please, can we just all work together for a world where the active window keeps focus until the user decides otherwise? Where websites are smart enough to change focus only if you're not currently interacting with the page, if they insist on changing focus at all?

Finally... Client Properties You Can Use

One of the Java Swing GUI toolkit's strong advantages is its flexible, easy-to-customize architecture. Swing isn't easy for beginners, but once you grok it, there are a lot of great ways to customize the behavior, state, and appearance of a widget. Indeed, if maximum flexibility is your goal, you'd be hard-pressed to find a better toolkit on any platform.

I used to hand-code all of my Swing code, including UI layouts. Thankfully, over the past year or two, several high-quality graphical UI layout tools have emerged, the first of which (that I noticed) was JFormDesigner -- which I still use. But there's one feature I really miss from the current generation: client property support.

I find myself constantly using client properties to extend the functionality of Swing components. For example, I'm a big fan of externalized formatting for Swing components, like what Guy Romain is doing with the Fuse project. While Fuse is annotation based, I'm a simpler guy -- I want to be able to define properties of Swing components in an external file (very much like a CSS file) and then apply those styles to Swing components by id (which I map to the JComponent's name property) and by "class". So, I can do something like:

JTextField.productCode {
    columns = 10;
    fontSize = 10pt;
    font-family = Helvetica,Arial,Dialog;
    border: 1dlu solid black;
}

and map that to all JTextField's with the "productCode" class. Ah, so how do I assign the productCode class to a component? Subclassing is of course a bad idea. I maintain that you should never, ever subclass Swing components to add general functionality to them (if you ever hope to leverage a single third-party component).

The answer, of course, is a client property. I can define a client property key "org.galbraiths.clarity.styleClass" and set the value to "productCode", and I've now got this great system for allowing all JComponent's to specify a class for styling. (I actually apply the styles via a decoration mechanism that applies to all component hierarchies before they are displayed, but that's another story.)

Alas, the current versions of JFormDesigner, NetBeans, and IDEA don't provide any support for setting client properties. Ugh. So I have to write some kind of custom code all over the place to do this, which I'm loathe to do. I suppose I could, but, frankly, it makes my WinForms developer friends laugh at me, and I hate that.

Fortunately, that's about to change. The next version of JFormDesigner introduces support for client properties. You go into the Preferences menu and define your standard client property keys, like so:

and then the property pallette lets you set those values:

Nice! I'm one step closer to my dream development environment for my Swing framework. The next version of IDEA's GUI builder will also support client properties; hopefully, NetBeans will too.

By the way, I'll be talking more about this, and will be sharing some of my code under a license anyone can use, at this year's JavaOne in my Swing session. If I've said something you particularly disagree with, make a rude comment to this blog, by all means, but even better -- come and heckle! Chet can't be the only one with rabble-rousers in the audience.

Give Me My Commodity Text Widget Features, Please

(Cross-posted on Married... with children)

One of OS X's pioneering features was giving check-as-you-type, right-click-suggest spell checking to every application that wanted it, free of charge. It's so nice to be able to focus on writing without worrying that I've made an obvious spelling error, or, even better, intentionally mispelling a word so I can get instant access to the right variation -- and being able to do this in almost any context.

Amazing that years later, something that useful and handy is absent from the Java Desktop stack* and Windows. In the meantime, Apple took it a step further with the latest release of OS X: a commodity dictionary.

The next text widget feature I want to see commoditized is auto-complete. I've been authoring some documents in XML and XHTML, and my text editor memorizes every word I've entered and offers autocomplete options (if I request them). It's addictive and productive. And I want it everywhere -- especially in my Swing applications.

* If the service isn't present natively (and on Windows/Linux I don't imagine it is), just provide a Java native version

Avalon Everywhere? Cross-platform Microsoft?

Another interesting announcement here at PDC is that Microsoft is creating a subset of their cool, fancy pants UI layer (formerly code-named Avalon, now WPF) on other platforms, including the Mac! In fact, one of the demos involved showing vector graphics rendered in Safari using a Microsoft plug-in.

This subset, called WPF/E, will be powered by XAML (their XML dialect for representing the UI) and JavaScript. Sound familiar? Yes, that's right -- Microsoft also announced a Dashboard clone for Windows Vista. Interesting...

Microsoft will never port .NET to other major operating systems, but to have a subset of Avalon available on other platforms is a bit of a curveball. In fact, in light of Firefox and Safari's upcoming support of SVG and Canvas (and in the future, 3D functionality), this move makes sense; Microsoft wants to provide their own proprietary solution to cut off this new cross-platform initiative.

Also, Microsoft's Ajax framework, Atlas, will target WPF/E. The WPF/E subset of Avalon will include all of the Avalon features (vector graphics, animations, etc.) less 3D, some of their XPS features (XPS == Microsoft PDF clone), and hardware acceleration.

In a WPF/E session, someone asked if Microsoft's WPF/E plug-in will be available in Firefox; the speaker dodged the question ("We hope such support will emerge...").

My first reaction to WPF/E is frankly disappointment that they wouldn't just embrace SVG, though what I've seen of 2D XAML makes it look a while lot like SVG with different attribute names and various other differences. I wonder if XSLT will do the trick there...

Lack of many of the Avalon features in WPF/E, notably hardware acceleration, really makes it seem that the strategy is to make apps work on other platforms, but make them work poorly compared to Windows -- motivating users to switch to a Windows platform.

Successful GUI Building... Today

I'm not surprised to find negative sentiments towards GUI builders of the kind recently voiced by the HackNot blog (and linked by John Reynolds). For a long time, I avoided GUI building in Java, finding it a terribly unpleasant exercise.

Over the past year, I've experienced a very pleasant change in attitude, and whereas last year I would have voiced ambivilance about using GUI tools, today I think you'd be crazy to avoid them.

In my experience, the number one reason why GUI builders hold appeal is that they often lead to an order of magnitude improvement in productivity over handcoding, especially amongst average-level Swing developers. I consider myself above average, and I see improvements in productivity around 2x-10x (perhaps higher) in my own work. I challenge anyone who refutes this to a code off; just check the No Fluff Just Stuff schedule to see when I'm going to be in your area -- or let's do it at JavaOne 2006.

Why such a radical increase? Frankly, I think its fairly obvious, but since HackNot's piece didn't acknowledge it as a factor, just consider that the domain of GUI design is, err, visual, and doing design by writing code either means you've got to get to the point where you can reliably visualize what your layout manager does in your head (emphasis on reliably, folks), or you wind up compiling and executing over and over again doing minor/major tweaking until you finally get it right. That cycle alone seems to indicate how a visual tool can speed the process up. Consider also that Karsten Lentzsch, the Swing community's resident visual expert, recommends that hand-coders layout the GUI on paper before attempting to code it. Again, not hard to see how using the visual tool can lead to a significant productivity improvement by allowing you to skip that step.

By the way, I need to mention that I'm not talking about using a GUI builder to do absolute positioning -- I'm talking about doing layout management with the GUI builder.

I think the negativity voiced by HackNot and others about GUI builders isn't a rejection of the productivity increase of the GUI layout -- I think its too obvious and powerful to refute. I think its really a response to the current way that the tools integrate with Java code. (Though again, anyone who thinks modern tools don't intergate well with layout managers needs to look again.)

The key to success with GUI builders is to eschew code generation. That's a really bad idea for a lot of reasons. The model I've come to favor is using GUI builders to generate a binary representation of the GUI that you load at run-time.

For example, I use a tool to build a GUI panel, save it to a file named "MyForm", and then at run-time I do something like this:

RuntimeForm myForm = loadRuntimeForm("MyForm");
JPanel container = myForm.getContainerPanel();

Using this approach, I don't have to worry about how the GUI builder generates code, how it names variables, etc. Its then easy for me to attach behaviors to this GUI:

JButton myButton = (JButton) myForm.getComponent("myButton");
myButton.addActionListener(...);

The key here is that you name the button "myButton" in your GUI tool (e.g., using the Swing "name" property). This approach also makes reusing common GUI elements easy. If I am working on design and notice that there's some common recurring pattern that can actually yield an ROI if I reuse it I save the reusable component off to a panel and combine it at run-time, in a fashion such as this:

RuntimeForm myForm = loadRuntimeForm("MyForm");
RuntimeForm subpanel = loadRuntimeForm("SomePanel");
JPanel somePanelParent = (JPanel) myForm.getComponent("somePanelParent");
somePanelParent.add(subpanel.getContainerPanel());

Of course, this process can be made much easier by adding some conventions / helper methods to your framework, but that's another story. (By the way, "RuntimeForm" is an abstraction layer that lets you use any GUI builder at any time, or XUL tools for that manner -- they all generate the same product at run-time: a Swing component hierarchy.)

HackNot mentions having to layout components differently depending on locale as an argument against GUI builders. This requirement can be pretty easily generalized into a Swing widget, or it can be realized as code that manipulates your loaded panel, whatever your pleasure. This seems a pretty weak case against GUI builders to me.

So to summarize, using modern GUI builders and the right techniques, you aren't stuck with absolute positioning, you can reuse GUI patterns easily, you get separation of concerns for free, you can do i18n easily (every decent GUI builder supports this, but that doesn't matter -- you can do it at run-time without tool support), and you get a huge increase in productivity.

Before I wrap up -- which GUI builder do I use? There are a number of high-quality GUI builders on the market today. My favorite such tool is JFormDesigner, created by one-man-show Karl Tauber; its killer feature is tight integration with JGoodies FormLayout. Of course, when Matisse is ready, it is looking like it will be the one to beat.

Stop worrying and learn to love GUI builders. Their time has come -- but just say "no" to code generation.

Greasemonkey Goodness

If you haven't already taken a look at Greasemonkey, you really ought to. Maybe even right now (note: Firefox required).

Greasemonkey is a Firefox extension that enables folks to modify the contents of a website in realtime. For example, if your favorite blog's comment textarea is too small, make it larger yourself. Forced to manually click a bunch of checkboxes? Automate it. A bunch of Greasemonkey scripts are available to fix general website problems, and a bunch more to add new functionality to popular websites.

This is huge. We've had to put up with poor user experiences in applications ever since the dawn of the desktop computer (some more than others). Being able to fix annoying website UI glitches is a wonderful experience.

But I want more. Some of my most frustrating experiences involve desktop applications (such as a certain personal finance software package); what's the equivalent of Greasemonkey for such apps? More relevant to this discussion, what's the equivalent for Java desktop apps? Could it be something like exposing the Swing component hierarchy to power users for manipulation through some sort of general tool?

Yikes. The web's innate separation of client and server tiers makes this kind of thing seem much safer to me. You can't use Greasemonkey to manipulate moving parts that aren't exposed to the UI tier; having somehow directly interface with the business logic tier of a desktop application scares me to no end.

If not a general Java state manipulator (a la modern debuggers), is it external scripting against a published API, like AppleScript or ActiveX? The general problem with this approach is that these APIs are often too coarse-grained to enable the type of powerful modifications that Greasemonkey make's simple. Automator on OS X is nice, but its not nearly powerful enough for this kind of interaction.

Maybe the equivalent could be a light-weight automation/user interaction API on top of Swing... a scripting interface that integrates with the new Rhino/JavaScript engine in Mustang? Interesting...

Regardless of the specific implementation, the notion of empowering users to customize the UI in ways the designer never intended seems so compelling as to be a feit accompli in the future of application development.

SVG Goodness

Over at my other home, I've been talking a little about SVG's role in this new Ajax re-labeling of good ol'e DHTML techniques. I find a future where manipulating vector graphics and HTML constructs through the same API (and hint hint, it ain't DOM) all in a browser very interesting.

But Java desktop developers don't have to wait until the future to start incorporating SVG into their applications. Thanks to the Batik project, Swing applications can embed gorgeous (and often interactive) SVG files into their UIs today. I think the Klondike solitaire and Spain map examples from Batik are particularly compelling.

While I've long advocated the SVG/Batik combination as an excellent way to create beautiful, data-driven static graphics, Firefox's upcoming SVG support has interested me in SVG's potential as a user interface technology (and having the Batik team recently release a 10x faster version of their project for my Mac certainly helped that along) to supplement or replace more traditional GUIs. Cool stuff...

This work is licensed under a Creative Commons License.