Eitan Suez's Blog

June 2005 Archives

swing layout managers and the web..

so another big theme regarding the java desktop track at javaone is layout managers. looks like they're really and finally solving many of the issues that developers have had with layout management in awt/swing. indeed project matisse is receiving much attention.

the current, almost defacto layout managers in swing these days are the tablelayout derivatives, namely the most excellent jgoodies forms library. this layout manager's philosophy has beauty in its simplicity: it does away with the complication of insets or margins by simply making commonplace the use of empty cells on a grid. so cells are used to both place components and as white space. the grid is very flexible and can be customized in a number of ways. the main advantage is that the layout manager listens to its child components and their size preferences. the other is the fact that you can customize alignment, fill policy, rowspan, and colspan per cell. with these simple ideas as building blocks, developers today are layout out pains in a relatively clean and painless manner.

so here's where things get interesting. on the web there's been a strong movement to erradicate html tables as a layout management tool. today using html tables for this purpose is taboo. yet html by design does not even address the issue of layout management. xul by contrast does. it provides very specific provisions for alignment, fill, and layout management in general.

now let's think about this for a moment: what is an html table? surprisingly it's eerily similar to the jgoodies forms layout manager: it's grid based, it observes/respects its child component preferred sizing behavior, and allows for colspan and rowspan, cell alignment, etc..

so what gives? in the swing world, the same design is a wonderful thing, embraced by all. yet on the web, the very same design is shunned. this comes to show that when people talk about "good" design or "bad" design, most of the time they're just talking about "design a la mode:" whatever is in fashion today.

so the moral of this little blogpiece is: don't be swayed by temporal currents: stick to your guns, even if they happen to be unpopular "aujourd'hui." before long the currents will change again.

ps: you gotta love san francisco: i'm posting this blog entry from an irish pub with free wifi (!) and a guiness by my side.

swing sessions at javaone..

i've been enjoying some of the desktop talks at javaone
this week. with swing, a common theme for a talk is: tips
and tricks to make swing run faster. so some of these
talks got me thinking..

so here's a problem:

the construction of swing components is an expensive operation.
if you're building a fairly dynamic ui in swing, one where you
create views on the fly, as a response to a user request, then
there is a performance cost to creating the objects that make
up that view.

( an example of such an app may be one that uses
the mdi metaphor: a jdesktoppane with one or more toolbar
panels used to plan or construct representations of objects
on a canvas)

so the typical solution is caching: create views and cache
them in a pool. whenever you need a view you ask the viewmanager
and it might give you a "second hand" view. so the notion
is: don't throw away expensive things; keep them around, you
don't know who might need them later.

the reason i'm writing this is because for swing you have to
roll this out yourself.

i think a generic solution, one that is orthogonal to the application
in question can be arrived at by writing a couple of aspects:
an aspect that overrides new() on swing components to check if
an existing view already exists in the pool and return that
instead. another aspect that intercepts garbage collection and
instead of throwing away the view, cleans it up, dusts it a little,
and puts it back in the pool or "reuse bin," so to speak.

this reminds me of a recent talk that my friend bruce tate
gave to our users group in austin, texas, that touched on dynamic
languages such as ruby. in ruby, the ability to intercept such
calls is intrinsic to the language, and so injecting such a feature
turns out to be a simpler task for the developer.

the reason i write this is that i'm lazy.
i want this feature, so that i can improve the performance of my swing
applications. but this is a generic concern. maybe there's
something already out there, maybe throwing the idea in the
communal pot can help trigger the creation of a new java.net
project. who knows?

I believe I can fly ;-)

On and off over the last few months, I've witnessed and have been a part of a very informal distributed conversation about a logo or mascot for the JUGs community[ies]. A number of JUG-affiliated developers from around the world contributed their ideas.

Bruno Souza then told me about an idea that has existed in the brazilian community for close to ten years: The Java Finch.

Well, now it's official: the java.net JUGs community has just announced its new mascot: Juggy the Java Finch.

After a number of discussions and thoughts on the matter over a period of a few weeks, I've come to the conclusion that I could not think of a better choice, for many reasons.

The mascot has been donated to all Java User Groups under the Creative Commons License. I really hope we'll start to see JUGs around the world adopt it and create their own unique, localized versions of the mascot.

This work is licensed under a Creative Commons License.