Ben Galbraith's Blog

June 2005 Archives

Classloading in J2EE Applications

I've spent the last two or three years doing a large amount of client-side Java development. In that world, there are a number of techniques for partitioning the various JARs that compose the application into distinct class loader domains.

For example, using the Eclipse RCP, you can define your application as a set of plug-ins and define exactly which JARs *other* plug-ins can see.

Consider the following scenario: I have two frameworks, Foo and Bar. Framework Foo depends on a library called Commons-Sniping 1.0, and Framework Bar depends on a different version of the same library (Commons-Sniping 3.2). Version 3.2 breaks a bunch of 1.0 APIs and introduces its own new stuff.

Having Foo, Bar, and both versions of Commons-Sniping exist in the same class loader domain is foolish with a capital F. Weird, exotic, and fun errors can and will occur at run-time. So, you make Foo and Bar plug-ins, and define that those plug-ins only expose the Foo and Bar API. As a result, only Foo can see Commons-Sniping 1.0, and only Bar can see Commons-Sniping 3.2. And, things are good.

So, the other day I had this problem in the context of a web application. Two frameworks relied on different versions of the same library, and versions were different by a major version (e.g., 2.x and 3.x). So, uh, what do I do?

I asked several J2EE developer friends whom I respect. And the answers I got from all were, "Uh, choose the latest version and hope for the best." Hmm...

Is this really the state-of-the-art for J2EE development? Do some app servers provide class loader partitioning services to web applications? Or do I have to do my own integration with one of the third-party plug-in engines out there? Or, do you just rely on libraries to not ever be backwards incompatible? How do you solve this problem?

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.