Created attachment 31723 [details]
screenshot

I've been thinking how we could solve this problem, but with no luck. It is not
a problem of GroupLayout specifically, but rather a more general issue of laying
out components which preferred size of one dimension depends on the actual size
in the other dimension.

Multi-line label that wraps text is such a component. Before it is laid out with
the given width, it computes its preferred size as it would have just one line
(which is the default state). So it returns height of one line. But once its
width is set, the label's preferred height changes. Thus building such layout is
a two-step process. Normally it is not a problem , it happens automatically, but
when you need to determine the preferred size of the whole window (pack() does
this), you get the preferred size after the first pass, which is not correct.
You can fix it by calling pack() once more...

This problem can happen with any component that does some wrapping and does not
have the other dimension clearly defined (e.g. also JList with layout
orientation set to HORIZONTAL_WRAP or VERTICAL_WRAP). It is a problem in
situation when you need the preferred size - you don't right until the layout is
built.

Sorry, but the form is a JPanel and it does not extend the pack() method. In my
case I use this panel in a DialogDisplayer. Please give me a workaround to fix it!

DialogDisplayer gives you a Dialog on which you can call pack(). (Once is 
enough because you get it with the first computatuion of layout already done.)

Created attachment 32706 [details]
Screenshot 2

Pack() against the DialogDisplayer does not work! See Screenshot 2 for details. 

Ok, I've finally tried it myself ;) It seems the label does not change its mind 
until it is painted. Just computing the layout is not enough. That's how html 
rendering happens to work...

Trying to wait for the label painted is ugly (and you'd see the dialog 
resizing), so better seems just to call paintImmediately on the label. This 
needs to be done _after_ setVisible(true) is called on the dialog, which is a 
problem if the dialog is modal... So overall it might look like this:

final Dialog dialog = DialogDescriptor...
dialog.addComponentListener(new ComponentAdapter() {
    public void componentShown(ComponentEvent e) {
        theLabel.paintImmediately(theLabel.getBounds());
        dialog.pack();
        dialog.removeComponentListener(this);
    }
});
dialog.setVisible(true);

Let me know if this works for you.

The code you wrote is working! But this solution is a little bit "terrible" and
unacceptable! I think that this absolute a bug in GroupLayout.
I can also fix this problem, if I add below the JPassword component a
JSeparator. Then the dialog is also shown correct, but without the Separator.
I seems that the GroupLayout always suppres parts of the "bottom" Component.

This can also be seen in the FormDesigner:
Build a panel like I used with the "default" space of the "bottom"-JPassword.
Then restart Netbeans and you can see, that the space is gone.
Then add a JSeparator below the JPassword and set the "botton" space again to
default. The Separatot is shown. Restart Netbeans and the Separator is
invisible, but now you have an acceptable "bottom"-border of the panel.

I hope that someone can fix this bug.

I can agree with you the solution is weird, but this is definitely a problem of 
the html rendering of JLabel, not of GroupLayout. The JLabel does not provide 
correct preferred size until it is laid-out first and painted. Then the layout 
must be computed again. All the symptomps you describe are result of this. We 
could make the GUI builder to accommodate this in the designer, but we can't 
influence the runtime behavior.

GroupLayout just exposes this problem - with other layout manager you would not 
be able to use the multiline label at all (or you'd have to hardcode its 
preferred size which makes it unusable).

Closing. We can't fix nor accommodate the JLabel's html rendering behavior. I'll
write an FAQ entry.

*** Issue 82510 has been marked as a duplicate of this issue. ***