Skip to main content

For My Next Trick, I'll Need a Volunteer

Posted by editor on October 3, 2006 at 9:41 AM PDT

Sign up for Swing extensibility

It's easy enough to mistake the idea of a Swing look-and-feel for a "skin" in customizable end-user applications like WinAmp. What's surprising is that this isn't a particularly apt metaphor. For one thing, L&F addresses issues that a "skin" might not care about, like the order of buttons in a dialog (which is totally different on the Mac and Windows). L&F's are large and fairly intense pieces of work whose scale and scope exceed those of skins.

That leaves open the idea of extending an L&F, not just cosmetically, but by adding some functionality that might be appropriate in a given context. This turns out to be hard because the L&F's weren't really built to be extended, leaving you with several bad options: subclass a component (at which point you're extending Swing, not the L&F), extend its UI delegate (which won't work across multiple L&F's), or do something crazy like hack the event queue.

Kirill Grouchnikov has been there, and in our Feature Article,
Enhancing Swing Applications, he introduces a solution, in the form of the laf-widget project:

The laf-widget project aims to address the issues outlined above, providing a common layer that is used in third-party look-and-feel implementations that:

  • Allows the UI delegate implementation of the specific look-and-feel to get the list of all extensions (widgets) available for the specific component, and subsequently instantiate and register them.
  • Allows the extension writer to write the widget targeted at a specific component (such as context edit menu for the text components), without worrying about how it will be found and registered at runtime and without targeting a specific look-and-feel implementation.

The interfaces defined by laf-widget have already been implemented by several look and feels, so read along to learn how to bring new functionality to Swing at this level of the API.

In Java Today,
the JavaPosse podcast has posted the final installment of Dick Wall's lengthy interview with ComputeCycles project leader Van Simmons. In the interview, Van talks extensively about the goals and concepts and uses of Jini, the proposal to make it an Apache project, and low-level details like security, Jini's configuration language, JERI, and more. The interview has been split into three parts and released as JavaPosse podcasts #82, #84, and #86.

The JavaTools incubated project NET2Java is "a new technology that helps you take an application written in Visual Basic or C# to the .NET platform, and translate it into a program written in Java source code." NET2Java translates .NET calls into corresponding Java calls, flagging calls it doesn't currently know how to translate. The process produces readable source code, preserving class names, method names and code comments.

A new SDK article takes an in-depth look at web services support in JDK 6. In Introducing JAX-WS 2.0 With the Java SE 6 Platform, Part 1, Robert Eckstein and Rajiv Mordani write "one of the most exciting new features of the Java Platform, Standard Edition 6 (Java SE 6) is support for the Java API for XML Web Services (JAX-WS), version 2.0. JAX-WS 2.0 is the center of a newly rearchitected API stack for web services, which also includes Java Architecture for XML Binding (JAXB) 2.0 and SOAP with Attachments API for Java (SAAJ) 1.3."

In today's Forums,
Patrick Wright provides and update and jargon-check on Swing data-binding and data-buffering projects in
Re: JSR 295 & DataBuffer status:
"No idea about 295. DataBuffer hasn't had any big edits yet (tho Dave checked in a few things, I think). I split it off from DataBinding in order to allow it to keep developing on its own since DataBinding isn't being actively pursued anymore. DataBuffer is buildable, has tests, had demos written against it (which need to be dusted off), etc."

Joshua Marinacci considers cross-platform drawing concerns in
Re: Is There A BalloonTip Component In Java?
"This sounds great. Yes, definitely post a screenshot. How are you doing this? Using JNI to call the native method and JAWT to get a handle to the toplevel window/container handle? It would definitely need an isTranslucencySupported() method of some kind. I don't know if we should distinguish transparency and translucency at the API level. I suppose it depends on what the native platform supports. OSX and Vista should be no problem. I don't know about XP or earlier. And it seems that X is a crapshoot, depending on what the user has configured"