Internal Error - tabbedPane - when tab labels are not visible.

[C4J]

If more tabs exist than can have their label text displayed then WindowBuilder has an error when rendering. The source below has a label "Oops" which forces the combined width of all the tab titles to push some tabs out of sight. If you try and render the page you get the error.

If you edit "Oops" down to "A" you will be able to view the design.

Tabs.java

Some diagnosis has come up with the following theory (thanks to Claude)
The exact line:

// org.eclipse.wb.swing/.../JTabbedPaneInfo.java:113
Rectangle bounds = CoordinateUtils.get(pane.getBoundsAt(i));

is passing the result of JTabbedPane.getBoundsAt(i) straight into CoordinateUtils.get(java.awt.Rectangle) (line 49 of CoordinateUtils.java), which dereferences o.x with no null check.

And JTabbedPane.getBoundsAt(int) is documented to return null — straight from the JDK 21 source:

▎ Returns the tab bounds at index. If the tab at this index is not currently visible in the UI, then returns null. If there is no UI set on this tabbedpane, then returns null.

So when one tab is wide enough that the UI delegate decides it isn't currently visible (e.g. it doesn't fit and gets clipped/scrolled out), getBoundsAt legitimately returns null and WindowBuilder NPEs.

Why long text triggers it specifically on macOS: WindowBuilder renders your Swing live in-process. On macOS the default L&F is Aqua, whose AquaTabbedPaneCopyFromBasicUI enables a scrollable / overflow
tab layout — tabs that don't fit in the visible header strip are treated as not-currently-visible and getTabBounds returns null for them. BasicTabbedPaneUI (Metal etc.) uses WRAP and always produces a
Rectangle, which is why the cross-platform L&F doesn't reproduce it.

Fix in WindowBuilder

Line 113 needs a null guard. Minimal patch in JTabbedPaneInfo.getTabs():

java.awt.Rectangle rawBounds = pane.getBoundsAt(i);
if (rawBounds == null) {
continue; // tab not currently visible — skip, don't NPE
}
Rectangle bounds = CoordinateUtils.get(rawBounds);
tabs.add(new JTabbedPaneTabInfo(this, component, bounds));

Worth reporting upstream — the Javadoc on getBoundsAt has documented the null return for years.

Workarounds (without patching WB)

Shorten the offending tab title so all tabs fit Aqua's header strip.
Force Metal at the top of Tabs.main (or in a static {} block) so WB renders with Metal instead of Aqua:
try { UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName()); }
catch (Exception ignored) {}
WindowBuilder evaluates static initializers and the constructor when rendering, so this swaps the UI delegate to BasicTabbedPaneUI and the NPE goes away.

[C4J]

If it helps I downloaded this repo, made the suggested change, rebuilt and installed into Eclipse and it does seem to fix the problem.

JTabbedPaneInfo.java

[ptziegler]

Thanks for looking into this.

Yes, as Claude correctly detected, the problem is caused by an improper handling of the return value from getBoundsAt(int). Whether this method returns null primarily depends on the TabbedPaneUI instance assigned to this JTabbedPane, which in return depends on the current LookAndFeel. On Windows and Linux, this is effectively always non-null, but evidently not on MacOS.

For a platform-independent example, you can use this snippet:

import java.awt.Rectangle;

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JTabbedPane;
import javax.swing.plaf.basic.BasicTabbedPaneUI;

public class TabBoundsExample {

	public static void main(String[] args) {
		JTabbedPane tabs = new JTabbedPane() {
			public void repaint(Rectangle r) {
				if (r != null) {
					super.repaint(r);
				}
			}
		};
		tabs.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT);
		tabs.addTab("Tab ", new JLabel());
		tabs.setUI(new AlwaysNullTabbedPaneUI());

		JFrame frame = new JFrame();
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		frame.add(tabs);
		frame.setVisible(true);
	}

	private static class AlwaysNullTabbedPaneUI extends BasicTabbedPaneUI {
		@Override
		public Rectangle getTabBounds(JTabbedPane pane, int index) {
			return null;
		}
	}
}

The idea of ignoring those improper tabs is good, but has to be done at a different place. See #1510. We already do this for other tabs, so this is just an extension of this filter.

[C4J]

Will a fix appear in a nightly build sometime - I generally use that version.

[ptziegler]

Will a fix appear in a nightly build sometime - I generally use that version.

Probably tomorrow once the branch build is green and has been merged back. I'll let you know once the nightly build is available.

[ptziegler]

The fix should now be included in https://download.eclipse.org/windowbuilder/updates/nightly/latest

[C4J]

Many thanks - most appreciated

[C4J]

Ok - so I have 2 Eclipse installs on my Mac now pointing to 2 workspaces with the same project in each. (Source code is here https://github.com/C4J/sftpTransfer - the actual frame I'm opening is :- https://github.com/C4J/sftpTransfer/tree/main/src/com/commander4j/gui/frame

When I open the JFrame with the nightly update I see this,

When I open the JFrame with the version I modified I see this,

I've not looked any deeper at the cause as yet.

[C4J]

First and Last tab maybe significant ?