Unhandled Eventloop Exception (MacOS 14.3.1)

[obscurestar]

Windowbuilder was working with this window until the last batch of changes I made to it. I get no warnings or compile errors in my project, the Windowbuilder Design tap just show up empty.

My project is opensource and after doing some digging, the error appears in this (small) commit:
obscurestar/choordinates@10c3ec9#diff-24bc5d99104ec827f095ecd47ae668ae04b178c150fd5750a9c31aa8502f89e9L136

and appears to be related to the creation of a new public constructor in the unrelated 'ToneChord' class. (Even with the removal of 'foo' object)

Below is the stack trace from the General Error log stack trace when I click the design tab for the 'Choordinates' window in my project.

java.lang.NullPointerException: String is null
at java.desktop/sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2925)
at choordinates.FretPanel.paintComponent(FretPanel.java:273)
at java.desktop/javax.swing.JComponent.printComponent(JComponent.java:1292)
at java.desktop/javax.swing.JComponent.paint(JComponent.java:1132)
at java.desktop/javax.swing.JComponent.print(JComponent.java:1274)
at java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:965)
at java.desktop/javax.swing.JComponent.printChildren(JComponent.java:1305)
at java.desktop/javax.swing.JComponent.paint(JComponent.java:1140)
at java.desktop/javax.swing.JComponent.print(JComponent.java:1274)
at java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:965)
at java.desktop/javax.swing.JComponent.printChildren(JComponent.java:1305)
at java.desktop/javax.swing.JComponent.paint(JComponent.java:1140)
at java.desktop/javax.swing.JLayeredPane.paint(JLayeredPane.java:586)
at java.desktop/javax.swing.JComponent.print(JComponent.java:1274)
at java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:965)
at java.desktop/javax.swing.JComponent.printChildren(JComponent.java:1305)
at java.desktop/javax.swing.JComponent.paint(JComponent.java:1140)
at java.desktop/javax.swing.JComponent.print(JComponent.java:1274)
at java.desktop/java.awt.GraphicsCallback$PrintCallback.run(GraphicsCallback.java:50)
at java.desktop/sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:75)
at java.desktop/sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:112)
at java.desktop/java.awt.Container.print(Container.java:2060)
at java.desktop/sun.lwawt.LWComponentPeer.print(LWComponentPeer.java:807)
at java.desktop/sun.lwawt.LWContainerPeer.print(LWContainerPeer.java:276)
at java.desktop/java.awt.GraphicsCallback$PeerPrintCallback.run(GraphicsCallback.java:103)
at java.desktop/sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:75)
at java.desktop/java.awt.Component.printAll(Component.java:3534)
at org.eclipse.wb.internal.swing.utils.SwingScreenshotMaker.makeShots(SwingScreenshotMaker.java:146)
at org.eclipse.wb.internal.swing.model.component.ComponentInfo.refresh_fetch(ComponentInfo.java:156)
at org.eclipse.wb.internal.swing.model.component.ComponentInfo.refresh_fetch(ComponentInfo.java:140)
at org.eclipse.wb.internal.swing.model.component.ContainerInfo.refresh_fetch(ContainerInfo.java:258)
at org.eclipse.wb.core.model.ObjectInfo.lambda$6(ObjectInfo.java:481)
at org.eclipse.wb.internal.core.utils.execution.ExecutionUtils.runDesignTime(ExecutionUtils.java:147)
at org.eclipse.wb.core.model.ObjectInfo.lambda$5(ObjectInfo.java:480)
at org.eclipse.wb.internal.swing.utils.SwingUtils$2.run(SwingUtils.java:78)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

[ptziegler]

The source code was quite helpful in understanding what's going on. Thanks! Though I fear there is quite a lot of things playing together which ultimately lead to the exception.

WindowBuilder is doesn't execute the following line in the Choordinates class. There are a couple of technical reasons for this but to put it simply, ChoordData is not a child of the JFrame and therefore ignored.

ChoordData.read();   //Initialize data structures from JSON file.

This means that the choordinates.json file is not read which then causes the ChoordData object to remain uninitalized. When the tuning in the FretPanel class is updated, getCurrentTuning() returns -1 and the if block is executed, rather than the else block, which then causes the string names to remain uninitialized.

public void updateTuning()
    {
    	ChoordData choord_data = ChoordData.getInstance();
    	
    	int tuning_id = choord_data.getCurrentTuning();
    	
    	if (tuning_id == -1)
    	{
    	     mNumStrings = 6;
    	}
    	else
    	{
    		ToneChord tuning = choord_data.getTuning(tuning_id);
    		mNumStrings = tuning.getNumNotes();
    		
    		for (int i=0;i<mNumStrings; ++i)
    		{
    			mStringNames[i] = tuning.getNote(i).getName();
    		}
    	}	
    }

But because the mNumStrings is set to 6, this then leads to an exception, because the drawString method accesses the still uninitialized string names.

for (int y=0; y<mNumStrings; ++y)
{
    g.drawLine(cell_size + cell_half, (y+1) * cell_size + cell_half, cell_size * fret_lines + cell_half, (y+1) * cell_size + cell_half);
    if (mLefty)
    {
        g.drawString(mStringNames[y], cell_half, (y+1) * cell_size + cell_half);
    }
    else
    {
        g.drawString(mStringNames[y], cell_half, (mNumStrings - y) * cell_size + cell_half);
    }
}

Even outside of WindowBuilder, you can reproduce this issue simply by renaming choordinates.json or by making it otherwise inaccessible by the program.

While it would obviously be ideal for WindowBuilder to handle this special case, I think the most straightforward solution would be to simply restore the default names that were removed as part of your commit:

if (tuning_id == -1)
{
    //No tuning set, default.
        mStringNames[0] = "E";
        mStringNames[1] = "A";
        mStringNames[2] = "D";
        mStringNames[3] = "G";
        mStringNames[4] = "B";
        mStringNames[5] = "e";
        mNumStrings = 6;
}

[obscurestar]

Ah ha! Thanks! And I apologize for the state of that code in it's early prototype state. It's been through massive refactoring and cleanup since I filed the report. The ChoordData instancing seems to be the real key to understanding. I should have guessed that! Once again, apologies for having put you through looking at early and clumsy code. Best, Samantha

…

On Tue, Jan 7, 2025 at 12:38 PM Patrick Ziegler ***@***.***> wrote: The source code was quite helpful in understanding what's going on. Thanks! Though I fear there is quite a lot of things playing together which ultimately lead to the exception. WindowBuilder is doesn't execute the following line in the Choordinates class. There are a couple of technical reasons for this but to put it simply, ChoordData is not a child of the JFrame and therefore ignored. ChoordData.read(); //Initialize data structures from JSON file. This means that the choordinates.json file is not read which then causes the ChoordData object to remain uninitalized. When the tuning in the FretPanel class is updated, getCurrentTuning() returns -1 and the if block is executed, rather than the else block, which then causes the string names to remain uninitialized. public void updateTuning() { ChoordData choord_data = ChoordData.getInstance(); int tuning_id = choord_data.getCurrentTuning(); if (tuning_id == -1) { mNumStrings = 6; } else { ToneChord tuning = choord_data.getTuning(tuning_id); mNumStrings = tuning.getNumNotes(); for (int i=0;i<mNumStrings; ++i) { mStringNames[i] = tuning.getNote(i).getName(); } } } But because the mNumStrings is set to 6, this then leads to an exception, because the drawString method accesses the still uninitialized string names. for (int y=0; y<mNumStrings; ++y) { g.drawLine(cell_size + cell_half, (y+1) * cell_size + cell_half, cell_size * fret_lines + cell_half, (y+1) * cell_size + cell_half); if (mLefty) { g.drawString(mStringNames[y], cell_half, (y+1) * cell_size + cell_half); } else { g.drawString(mStringNames[y], cell_half, (mNumStrings - y) * cell_size + cell_half); } } Even outside of WindowBuilder, you can reproduce this issue simply by renaming choordinates.json or by making it otherwise inaccessible by the program. While it would obviously be ideal for WindowBuilder to handle this special case, I think the most straightforward solution would be to simply restore the default names that were removed as part of your commit: if (tuning_id == -1) { //No tuning set, default. mStringNames[0] = "E"; mStringNames[1] = "A"; mStringNames[2] = "D"; mStringNames[3] = "G"; mStringNames[4] = "B"; mStringNames[5] = "e"; mNumStrings = 6; } — Reply to this email directly, view it on GitHub <#975 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADRMRQZL5EPED4M3AEPYJ632JQ3LPAVCNFSM6AAAAABUW62CHSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZWGE3TOMZVGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ptziegler]

No worries :) But this is sadly not a trivial class to parse for the editor and I don't think that's something that'll be fixed anytime soon. So as I said, I think the path of least resistance would be to simply add the default case for the tuning and then the editor should -for the most part- be functional again.

[obscurestar]

Actually i got it to work again in later revisions thanks to your insights. The panel is blank in the preview but that's actually fine. I only really needed it for laying out controls in the rest of the display.

…

On Mon, Jan 20, 2025 at 12:27 PM Patrick Ziegler ***@***.***> wrote: No worries :) But this is sadly not a trivial class to parse for the editor and I don't think that's something that'll be fixed anytime soon. So as I said, I think the path of least resistance would be to simply add the default case for the tuning and then the editor should -for the most part- be functional again. — Reply to this email directly, view it on GitHub <#975 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADRMRQ26RSASBVUTVRWSFYD2LVLZTAVCNFSM6AAAAABUW62CHSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBTGE4DKNZTGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>