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.

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!

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.

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.

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).

Over at Ajaxian, I just posted a ~30 minute podcast exploring this issue, featuring interviews with Brendan Eich (CTO, Mozilla), Kevin Lynch (Chief Software Architect, Adobe), Alex Russell (Dojo Lead), and many others. I had a lot of fun recording the interviews and editing this together, but I probably spent a little too much time doing it. ;-)

I'm interested in knowing if folks enjoy this kind of "feature" podcasts that involve more of a narrative than traditional monologue or interview podcasts. They take a lot of time to produce, but I kind of like having the information dense and relevant to a particular subject...

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

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)

Check it out and let me know what you think!

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!

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!

My first reaction was to conclude that the process required 15 MB of heap in order to complete. But of course, that's an erroneous conclusion. With different settings or constraints, perhaps the process would have added only 7 MB of garbage before the collector cleaned the heap.

What I really need to know is the size of the largest set of strongly referenced object data placed on the heap as a result of the process at any one time. Because I can reasonably isolate the process, I'd settle for a definite measurement of the strongly referenced objects on the heap at any one time.

So how do I figure this out? I've used a number of tools that show me the size of the heap over time. Some let me take a snapshot of the heap and remove all weakly-referenced data. But I have yet to find a tool that will, over a period of time, tell me what the largest amount of the uncollectable heap data is (in bytes).

Anyone know of tool or process to figure this out? I know I could reduce the heap size until the process throws an OutOfMemoryException. I'm looking for something a little more automated.

Dion Almaer and I were given the opportunity to deliver a talk on Ajax at JavaOne earlier this year. The session went pretty well, and I found myself giving a repeat on the last day of JavaOne that also went pretty well. Many thanks to those of you that attended and especially to those of you that gave us feedback both in person after the talks or via the eval forms.

One of the things a lot of you told us was that you wished we went into greater depth in some area of Ajax. Indeed, in a 60 minute session, we had to leave a lot unsaid.

I'm happy to say that for those of you that were left a little wanting, the Ajax firehouse is wide open: Dion and I are hosting a conference in Boston next month (www.theajaxexperience.com) where sixty 90-minute sessions will be delivered over the course of three days. We've got a ton of Java-specific content, including the lead of Google's Java-based GWT framework, the lead of the excellent DWR framework, and one of the core Spring developers.

Desktop Conference

A while back, I solicited feedback here on the possibility of giving a Desktop Developer's Conference. I'm happy to say that I'm moving forward with this concept. At first, I was going to make it a Java, .NET, and Cocoa/ObjC affair, but as I evaluated the marketplace, I decided to give it a Java focus. I've seen a few .NET conferences start and then abruptly stop, and I've seen no precedent for a Cocoa conference, so I got cold feet building out a lot of content for those technologies.

But, I still am planning on having Microsoft show up and talk to us about both WinForms and Windows Presentation Foundation (WPF). And, I'm still planning on having Apple show up to talk about Cocoa. Nothing like seeing how the other half (1/3?) lives.

I would like some more feedback on a few things:

1. How much (if any) SWT/Eclipse content should there be? Anyone have any strong feelings one way or the other? It's hard for me to get a good read on this -- not a lot of hard data and my own experience suggests that SWT/JFace/EclipseRCP usage is a small fraction of Swing, but I could be off-base here.

2. Should this be a multi-track event or a one-track event? If multi-track, should it be a large track event like The Ajax Experience with six tracks, should it be mini-track with 2-3, or mega-track like JavaOne with 10 tracks+ (like I could find that much desktop content)?

Thanks,

Ben

One of the things I enjoy about fatherhood is being, for however brief a period, somewhat of an authority on life. Well, thanks to Duke, the appearance of parental infallibility has come to an early end.

Ever since JavaOne 2006 (where I got this nice green shirt), I've had to deal with all kinds of questions from my four and two year old daughters:

Girls: "Daddy, what's that on your shirt?"

Me: "Err, that's Duke."

Girls: "What is he?"

Me: "Hmm."

Girls: "Is he a bird? I think he's a bird."

Me: "No, he's not a bird. He's, uh, a cartoon character."

Girls: "He looks like a bird."

Me: "No, he's a cartoon mascot for Java."

And now, every time I wear it, I have to deal with a variant of this conversation. Like this morning:

Girls: "Is that Duke? What is he?"

And so forth. I'm just waiting for one of them to say, "Well, what exactly do you know, daddy?" and to hear them whispering amongst themselves: "Don't bother asking daddy that, he doesn't even know what Duke is."

Why can't Java have a recognizable noun as a mascot? Like a bird? Or even a horse? Here's for Mustang shirts at next JavaOne. Actually, too bad we can't go back and have Merlin shirts made. That could have been really cool...

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