But you spend much more time trying to figure how
to attach ComponentListener(s) or monitoring a 'DPI
change' rather than simply allowing a LayoutManager
(or LayoutManager*s* in the case of a nested layout)
to figure how to distribute the available space amongst
the components.

I did an experiment since this thread started, changing
my 96 DPI Widows computer to 120 DPI.  Every one of
my GUIs (using standard J2SE Layouts) looks entirely
logical to the new DPI, without any need of 'knowing'
either the screen size, or DPI.  Note that this 'logical'
look is more a testament to the clever people that designed
the layouts, than anything to do with me - I just invoked
their (well designed) logic in my GUIs.

I agree GridBagLayout is complex (and quirky). That is why I often use
* Nested layouts (e.g. BoxLayout inside BoxLayout)
* MigLayout. More powerful than GridBagLayout, easier, free and concise.

A simple example from http://www.miglayout.com/QuickStart.pdf

+-----+-------------+-----+

+-----+    comp2    +-----+

+-----+--------+----+-----+

+-----+--------+----+-----+

panel = new JPanel(new MigLayout());
panel.add(comp1);
panel.add(comp2, "span 2 2");
panel.add(comp3, "wrap");
panel.add(comp4);
panel.add(comp5);
panel.add(comp6);
panel.add(comp7);

I doubt I could do that as easily using a null layout. YMMV

Sizes can be specified in units that take DPI into account (points ,cm,
inches etc) It also has "logical pixels" which caters for varying sizes
of "normal" font on the platform.

You can specify which components grow to grab available space as the
container is resized (weighted, grouped), alignment, insets, equalize
button sizes, etc etc etc. It can mimic flowlayout and borderlayout as
well as grid oriented layouts.

It can also do absolute positioning, or a mix!

I added MigLayout's source to my workspace, so using and deploying is ,
for me, the same as for any standard layout manager.

Note: I'm not associated with Mig in any way other than as a happy user
of MigLayout.

Although GridBagLayout is complex, it is one of
the weaker Java layout managers.

Since this has been mentioned in this thread:
I've found in layout courses that most developers
end up with better design if they use a flat
grid-based layout and avoid nesting.
There are design-cases where nesting makes sense;
as a general guideline it should be avoided in
Swing, because otherwise you loose layout constraints
required for aligning (sub-)elements. Swing LMs
do not provide inter-panel layout constraints.

I've also found in the layout courses that many
developers face problems with building a mental
layout when reading layout code that mixes the
design specification with the panel building.
That's the case for GridBagLayout and how
MIGLayout is advertised. If you have 50 components,
even the last constraint can change the number
of columns.
In contrast TableLayout has invented a style where
the developer can understand the layout specification
by reading a few lines of code. That's the fixed part.
The longer panel building part does not affect
the overall design (columns, often rows).

I provide a free and open layout system that aims
to address the needs of developers as well as the
requirements for useable visual tools, the JGoodies
Forms. It has been designed to make it easier to
find a layout (it's grid based), and to implement
with hand or tool. The JGoodies FormLayout has visual
plugins for Eclipse, Netbeans and is integrated with
IDEA.

Here's more information:
http://www.jgoodies.com/freeware/forms/index.html

-Karsten Lentzsch