- waiting to lock <0x00000000e1139ea8> (a java.lang.Class for java.awt.Window)
at java.awt.Window.init(java.desktop@19.0.1/Window.java:506)
at java.awt.Window.<init>(java.desktop@19.0.1/Window.java:554)
at java.awt.Frame.<init>(java.desktop@19.0.1/Frame.java:428)
at java.awt.Frame.<init>(java.desktop@19.0.1/Frame.java:393)
at javax.swing.JFrame.<init>(java.desktop@19.0.1/JFrame.java:180)
at de.gurkenlabs.litiengine.GameWindow.<init>(GameWindow.java:61)
at de.gurkenlabs.litiengine.Game.init(Game.java:471)
Describe the bug Game.class is deadlock prone, as it calls swing methods outside of a swing thread. (See #764)
Users are instructed to just call
Game.init
, but this is actually unsafe. In order to not be deadlock prone, they would actually have to callIt seems someone actually thought of this in Utiliti here: 9b586928a97143892550a50244a0443da12eb9f3
Locktrace: