almost all don't.

but all should.

We even have design patterns to help us: MVC, MVP, Humble Dialog Box,
Observer, Etc.

The display code is still in Java, but its only concerned with display
not content.

However, recently there have been a few none java gui rendering
tools/techniques appearing: xaml, xul, etc

Andrew

It's unusual to set fixed sizes, colours, fonts, etc., for standard
widgets. If an application program started setting those sort of
attributes, the widgets would look very out of place. Most appearance
details is handled by the Pluggable Look & Feel (PL&F).

There are properties set on widgets by the application program that are
locale dependent. Labels, mnemonics, that sort of thing. It's easy
enough to write methods that applies properties read from a properties
file to a widget with a given name.

Most programmers seem to take a ball of mud attitude to GUI programming.
I prefer to use layers. The top layer just lays out components. The
layer beneath creates components. Another layer manages the underlying
models.

Tom Hawtin

If you're seeing tight coupling it is probably because the book is
keeping examples simple.

Separating the objects from the presentation is what the LayoutManager
interface is all about.

Swing has "Look&Feel" that parameterizes widget behavior and drawing
down-to-the-metal.

Here's an article where the author maps the CSS idea onto Swing:

http://today.java.net/pub/a/today/2003/10/14/swingcss.html

That might be because the book has to keep examples simple.  OTOH, it could be
bad code in that it hard-codes layout at the pixel level (but that could also
be in order to keep things simple until it gets to layout managers in some
(hypothetical) later chapter -- but I would still call it a bad example, even
so).

But, to the extent that the book's examples are representative of real code, I
hope you'll find that that stuff /is/ display.  Only display.  Content is -- or
damn-well should be -- handled elsewhere.

   -- chris