Multiple row column-sharing with GridBadLayout does not work as expected

Question

I was trying to figure out why I could not initially accomplish the following with a GridBagLayout:
Row0: 0000011111
Row1:      1111122222
Row2:           2222233333The above is supposed to be 3 JLabels on three different rows:
The 1st row has a single JLabel starting in column 0 with a width of 2, extending it to column 1.
The 2nd row has a single JLabel starting in column 1 with a width of 2, extending it to column 2.
The 3rd row has a single JLabel starting in column 2 with a width of 2, extending it to column 3.
The entire grid is 4 columns and 3 rows total.
Below I have two examples where I attempted the above. Only the 2nd example produces the desired effect. The 1st code example ends up putting both the Row 0 and Row 1 JLabel in the same column. This was surprising because I thought the GridBagLayout would give each column contained by a control enough weight to actually make those columns exist.
Here is what my first code example below produces:
Row0: 0000011111
Row1: 1111122222
Row2:           2222233333The first two JLabels, 0000011111 and 1111122222, appear in the same column, and the 3rd JLabel appears in the seemingly 2nd column. This was confusing to me which is the point of this whole post.
In order to gain the desired effect, I had to place 4 blank dummy empty JLabel components in a non-visible Row 0 of the grid. I did this for all 4 columns of that invisible row 0. The row is non-visible because the JLabel have no text or output. After adding this non-visible Row 0, all of the original mentioned Rows 0 through 2 become Rows 1 through 2 respectively.
For example:
Row0: iiiiiIIIIIiiiiiIIIII
Row1: 0000011111
Row2:      1111122222
Row3:           2222233333The above shows an inserted Row 0 with invisible labels that are not seen, but they seem to give weight to each column, allowing each to exist. Without doing this, as mentioned, the first code example (shown below) fails. The second example (also below) works, so it appears that putting the invisible controls into the first row, one in each column, somehow gives enough weight to each column to "establish" the column more so than otherwise.
The big question I have is why didn't the first example work?
I mean, in that example, I'm giving each JLabel equal weight, and each one takes up a width of 2 columns, so why doesn't the JLabel in the second row end up in column 1? Instead, both the original row 0 and row 1 JLabels appear in what looks like column 0, the same column. Does anyone know why this happened?
The invisible control solution is fine but I'm just curious why it wasn't as intuitive as it should have been. The only thing I can come up with is that the weight of the 1st and 2nd JLabel (row 0 and 1) got combined in some fashion which combined them into column 1 which end up looking like column 0 since 0 somehow looses all weight. (???)
****************** THE FOLLOWING DOES NOT PRODUCE THE RIGHT EFFECTS ******************
public class TestCoincidingColumns1 extends javax.swing.JFrame {
    /** Creates new form TestCoincidingColumns1 */
    public TestCoincidingColumns1() {
        initComponents();
    /** This method is called from within the constructor to
     * initialize the form.
     * WARNING: Do NOT modify this code. The content of this method is
     * always regenerated by the Form Editor.
    @SuppressWarnings("unchecked")
    // <editor-fold defaultstate="collapsed" desc="Generated Code">
    private void initComponents() {
        java.awt.GridBagConstraints gridBagConstraints;
        jLabel1 = new javax.swing.JLabel();
        jLabel2 = new javax.swing.JLabel();
        jLabel3 = new javax.swing.JLabel();
        setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);
        getContentPane().setLayout(new java.awt.GridBagLayout());
        jLabel1.setText("LabelRow0Col0Wid2");
        jLabel1.setBorder(javax.swing.BorderFactory.createLineBorder(new java.awt.Color(0, 255, 255)));
        gridBagConstraints = new java.awt.GridBagConstraints();
        gridBagConstraints.gridx = 0;
        gridBagConstraints.gridy = 0;
        gridBagConstraints.gridwidth = 2;
        gridBagConstraints.fill = java.awt.GridBagConstraints.HORIZONTAL;
        getContentPane().add(jLabel1, gridBagConstraints);
        jLabel2.setText("LabelRow1Col1Wid2");
        jLabel2.setBorder(javax.swing.BorderFactory.createLineBorder(new java.awt.Color(255, 0, 0)));
        gridBagConstraints = new java.awt.GridBagConstraints();
        gridBagConstraints.gridx = 1;
        gridBagConstraints.gridy = 1;
        gridBagConstraints.gridwidth = 2;
        gridBagConstraints.fill = java.awt.GridBagConstraints.HORIZONTAL;
        getContentPane().add(jLabel2, gridBagConstraints);
        jLabel3.setText("LabelRow2Col2Wid2");
        jLabel3.setBorder(javax.swing.BorderFactory.createLineBorder(new java.awt.Color(0, 255, 0)));
        gridBagConstraints = new java.awt.GridBagConstraints();
        gridBagConstraints.gridx = 2;
        gridBagConstraints.gridy = 2;
        gridBagConstraints.gridwidth = 2;
        gridBagConstraints.fill = java.awt.GridBagConstraints.HORIZONTAL;
        getContentPane().add(jLabel3, gridBagConstraints);
        pack();
    }// </editor-fold>
    * @param args the command line arguments
    public static void main(String args[]) {
        java.awt.EventQueue.invokeLater(new Runnable() {
            public void run() {
                new TestCoincidingColumns1().setVisible(true);
    // Variables declaration - do not modify
    private javax.swing.JLabel jLabel1;
    private javax.swing.JLabel jLabel2;
    private javax.swing.JLabel jLabel3;
    // End of variables declaration
****************** THE FOLLOWING WORKS ******************
public class TestCoincidingColumns1WithFix extends javax.swing.JFrame {
    /** Creates new form TestCoincidingColumns1WithFix */
    public TestCoincidingColumns1WithFix() {
        initComponents();
    /** This method is called from within the constructor to
     * initialize the form.
     * WARNING: Do NOT modify this code. The content of this method is
     * always regenerated by the Form Editor.
    @SuppressWarnings("unchecked")
    // <editor-fold defaultstate="collapsed" desc="Generated Code">                          
    private void initComponents() {
        java.awt.GridBagConstraints gridBagConstraints;
        jLabel1 = new javax.swing.JLabel();
        jLabel2 = new javax.swing.JLabel();
        jLabel3 = new javax.swing.JLabel();
        DummyRow0Col0 = new javax.swing.JLabel();
        DummyRow0Col1 = new javax.swing.JLabel();
        DummyRow0Col2 = new javax.swing.JLabel();
        DummyRow0Col3 = new javax.swing.JLabel();
        setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);
        getContentPane().setLayout(new java.awt.GridBagLayout());
        jLabel1.setText("LabelRow0Col0Wid2");
        jLabel1.setBorder(javax.swing.BorderFactory.createLineBorder(new java.awt.Color(0, 255, 255)));
        gridBagConstraints = new java.awt.GridBagConstraints();
        gridBagConstraints.gridx = 0;
        gridBagConstraints.gridy = 1;
        gridBagConstraints.gridwidth = 2;
        gridBagConstraints.fill = java.awt.GridBagConstraints.HORIZONTAL;
        gridBagConstraints.weightx = 1.0;
        getContentPane().add(jLabel1, gridBagConstraints);
        jLabel2.setText("LabelRow1Col1Wid2");
        jLabel2.setBorder(javax.swing.BorderFactory.createLineBorder(new java.awt.Color(255, 0, 0)));
        gridBagConstraints = new java.awt.GridBagConstraints();
        gridBagConstraints.gridx = 1;
        gridBagConstraints.gridy = 2;
        gridBagConstraints.gridwidth = 2;
        gridBagConstraints.fill = java.awt.GridBagConstraints.HORIZONTAL;
        gridBagConstraints.weightx = 1.0;
        getContentPane().add(jLabel2, gridBagConstraints);
        jLabel3.setText("LabelRow2Col2Wid2");
        jLabel3.setBorder(javax.swing.BorderFactory.createLineBorder(new java.awt.Color(0, 255, 0)));
        gridBagConstraints = new java.awt.GridBagConstraints();
        gridBagConstraints.gridx = 2;
        gridBagConstraints.gridy = 3;
        gridBagConstraints.gridwidth = 2;
        gridBagConstraints.fill = java.awt.GridBagConstraints.HORIZONTAL;
        gridBagConstraints.weightx = 1.0;
        getContentPane().add(jLabel3, gridBagConstraints);
        gridBagConstraints = new java.awt.GridBagConstraints();
        gridBagConstraints.gridx = 0;
        gridBagConstraints.gridy = 0;
        gridBagConstraints.weightx = 1.0;
        getContentPane().add(DummyRow0Col0, gridBagConstraints);
        gridBagConstraints = new java.awt.GridBagConstraints();
        gridBagConstraints.gridx = 1;
        gridBagConstraints.gridy = 0;
        gridBagConstraints.weightx = 1.0;
        getContentPane().add(DummyRow0Col1, gridBagConstraints);
        gridBagConstraints = new java.awt.GridBagConstraints();
        gridBagConstraints.gridx = 2;
        gridBagConstraints.gridy = 0;
        gridBagConstraints.weightx = 1.0;
        getContentPane().add(DummyRow0Col2, gridBagConstraints);
        gridBagConstraints = new java.awt.GridBagConstraints();
        gridBagConstraints.gridx = 3;
        gridBagConstraints.gridy = 0;
        gridBagConstraints.weightx = 1.0;
        getContentPane().add(DummyRow0Col3, gridBagConstraints);
        pack();
    }// </editor-fold>                        
    * @param args the command line arguments
    public static void main(String args[]) {
        java.awt.EventQueue.invokeLater(new Runnable() {
            public void run() {
                new TestCoincidingColumns1WithFix().setVisible(true);
    // Variables declaration - do not modify                     
    private javax.swing.JLabel DummyRow0Col0;
    private javax.swing.JLabel DummyRow0Col1;
    private javax.swing.JLabel DummyRow0Col2;
    private javax.swing.JLabel DummyRow0Col3;
    private javax.swing.JLabel jLabel1;
    private javax.swing.JLabel jLabel2;
    private javax.swing.JLabel jLabel3;
    // End of variables declaration                   
}

Answer 1

I think I figured out the general reason for the problem based on a quick trace through of the GridBadLayout code in a simple example, and I wanted to share my findings in case they may be useful to anyone else. I felt there were some concepts gleaned from the source code that don't appear reinforced with documentation or, more importantly, in tutorials or books I checked. That's why I wanted to share my findings with this simple yet perplexing example.
This example is very much like the one in my original post except it is more simple and only uses two JLabels.
I created a grid with the following settings:
JLabel1,gridx=0,gridy=0,gridwidth=2,weightx=1.0
JLabel2,gridx=1,gridy=1,gridwidth=2,weightx=1.0Using the character '1' for JLabel1, and the character '2' for JLabel2, and 'x' for an "empty" grid cell, the above gives me the following simple conceptual layout:
11x
x22But the 'x' cell columns don't receive any weight, so things actually appear as follows:
11
22Internally, GridBagLayout (GBL), is really producing the following:
11x
x22But since the 'x' locations take no weight, they therefore get no size, so both JLabels appear as though they are in the first and only column.
From what I can see, it doesn't really matter what I do, I'll never be able to produce the following effect with just two JLabels:
11x
x22I cannot do the above with just two JLabel components and a GridBagLayout. The reason is that the GridBagLayout, while it does define a "grid" of rows and columns, the grid is not a grid that actually relates to what is displayed. It's really a grid that defines what I'll refer to as "weight collisions" or "weight pools." If two components share, say, a grid column, their weights will combine with respect to that column. But the total size of the grid doesn't play a role in enforcing that some sort of grid display is maintained. The grid can possibly do that, but it would probably be safer to view that result as a side-effect produced by using the "weight pools" created by the grid itself.
In the above simple example, JLabel1 ends up giving gridx 1 (0 being first) its full weight of 1.0. The gridx 0 column receive zero weight from JLabel1. What happens is the code in GridBagLayout sees that there are no presently assigned weights to column 0 and it simply assigns all remaining unassigned weight of JLabel1 to JLabel1's last, right-most in this case, gridx column. This means that gridx 1 gets the full 1.0.
By contrast, though, when processing JLabel2, the GridBagLayout sees the previously assigned 1.0 to gridx 1 (JLabel1's right-most grid column) and it ends up assigning all of JLabel2's weight to that same grid location, gridx 1. In this case, even though JLabel2 supposedly spans through to gridx 2, the actual gridx 2 column gets 0 weight from JLabel2 and therefore gets no width.
The result is that both JLabel1 and JLabel2 give 100% of their weight to gridx column 1 (what I called above a "weight pool" rather than a grid location), and both gridx 0 and gridx 2 receive 0 weight and I'm guessing appear without any size. What's odd about this is that even though JLabel1 starts at gridx=0, it really doesn't draw itself anywhere but starting at gridx=1. Likewise, even though JLabel2 draws itself supposedly from gridx=1 through to gridx=2, it doesn't really go into gridx=2 because gridx=2 doesn't get any width.
In fact, given the code in GridBagLayout, it doesn't matter how much weight I give to either JLabel, all 100% of the weight will end up in gridx 1, the "center" grid location. The only way to get columnar distribution is to create other components to force the GridBagLayout to see individual columns which match the "grid." When I do this, the columns allow me to create the JLabels in a fashion where they intent/stagger, where a JLabel can start at a "column" location that is in the middle of another JLabel.
Given this, I've come to the conclusion that it's not worthwhile to look at the GBL "grid" as a grid that propagates grid-like visual locations. It's more like the grid exists during the computation of weights which end up determining the true columns and rows that will visually exist, which may well not be anything like the grid locations one might visualize when looking at the constraints used.
I think it's unfortunate that many examples and tutorials don't reinforce this concept with simple examples that help one grasp this easily. Most examples I see actually can fool a user into thinking a grid is a true grid in that positions represent visual locations, or that a control spanning into a grid column means that weight will be (at least) partially distributed there.
You very often won't see the problem I'm describing above when you have dialogbox-like alignment of components which most tutorials and examples utilize. For example, if I take the same example as above, but intent JLabel so that it's gridx is 2, not 1, then both JLabels will not be sharing a single grid column so their weights won't collide. In such a case, one might be misled into thinking that a GridBagLayout's grid is truly providing row/col locations when it's not really doing that. Instead, in this latter case, one is really gaining that effect because certain unintuitive weight collisions. which would produce unexpected results, are being avoided.
I thought weightx values would give a weight equally to all gridx columns that a component spans but that doesn't seem to be the case here. In fact, it's not even a components first column in my simple example above. GBL causes JLabel1 to given all its weight to gridx=1 (and nothing to gridx=0) while GBL causes JLabel2 to give all its weight to gridx=1 (and nothing to gridx=2). In one case, JLabel1, all weight goes to its right-most spanned-to column, while with JLabel2, it goes to JLabel2's entire first gridx location.
I guess this is what makes GridBagLayout (GBL) unintuitive. But I don't think it's so much unintuitive as it is probably not well documented. When you look at the source code, it explains stuff which should be in the docs. In fact, not one single book I saw gave any help in solving this problem. I'm guessing this is largely because folks use GBL through trial and error until they get what they want, and perhaps they don't often need to indent halfway as I'm trying to do with GBL in the above example. If a lot of components are aligned, the results are not as unexpected. I'd say, though, that even in those not-so-confusing cases, GBL can troublesome without knowing its grid is all about a grid of weight pools which may or may not produce a visual grid depending on all components' constraint settings.