ConcurrentModificationException during DPI change

[HeikoKlare]

I just faced the following ConcurrentModificationException aborting the DPI update and leaving an inconsistent UI state (some widgets scaled while other are not):

java.util.ConcurrentModificationException
	at java.base/java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1521)
	at java.base/java.util.TreeMap$EntryIterator.next(TreeMap.java:1557)
	at java.base/java.util.TreeMap$EntryIterator.next(TreeMap.java:1552)
	at org.eclipse.swt.internal.DPIZoomChangeRegistry.applyChange(DPIZoomChangeRegistry.java:51)
	at org.eclipse.swt.widgets.Composite.handleDPIChange(Composite.java:1987)
	at org.eclipse.swt.internal.DPIZoomChangeRegistry.applyChange(DPIZoomChangeRegistry.java:55)
	at org.eclipse.swt.widgets.Composite.handleDPIChange(Composite.java:1987)
	at org.eclipse.swt.internal.DPIZoomChangeRegistry.applyChange(DPIZoomChangeRegistry.java:55)
	at org.eclipse.swt.widgets.Composite.handleDPIChange(Composite.java:1987)
	at org.eclipse.swt.internal.DPIZoomChangeRegistry.applyChange(DPIZoomChangeRegistry.java:55)
	at org.eclipse.swt.widgets.Composite.handleDPIChange(Composite.java:1987)
	at org.eclipse.swt.internal.DPIZoomChangeRegistry.applyChange(DPIZoomChangeRegistry.java:55)
	at org.eclipse.swt.widgets.Composite.handleDPIChange(Composite.java:1987)
	at org.eclipse.swt.internal.DPIZoomChangeRegistry.applyChange(DPIZoomChangeRegistry.java:55)
	at org.eclipse.swt.widgets.Composite.handleDPIChange(Composite.java:1987)
	at org.eclipse.swt.internal.DPIZoomChangeRegistry.applyChange(DPIZoomChangeRegistry.java:55)
	at org.eclipse.swt.widgets.Composite.handleDPIChange(Composite.java:1987)
	at org.eclipse.swt.internal.DPIZoomChangeRegistry.applyChange(DPIZoomChangeRegistry.java:55)
	at org.eclipse.swt.widgets.Composite.handleDPIChange(Composite.java:1987)
	at org.eclipse.swt.internal.DPIZoomChangeRegistry.applyChange(DPIZoomChangeRegistry.java:55)
	at org.eclipse.swt.widgets.Composite.handleDPIChange(Composite.java:1987)
	at org.eclipse.swt.internal.DPIZoomChangeRegistry.applyChange(DPIZoomChangeRegistry.java:55)
	at org.eclipse.swt.widgets.Composite.handleDPIChange(Composite.java:1987)
	at org.eclipse.swt.internal.DPIZoomChangeRegistry.applyChange(DPIZoomChangeRegistry.java:55)
	at org.eclipse.swt.widgets.Composite.handleDPIChange(Composite.java:1987)
	at org.eclipse.swt.internal.DPIZoomChangeRegistry.applyChange(DPIZoomChangeRegistry.java:55)
	at org.eclipse.swt.widgets.Control.WM_DPICHANGED(Control.java:4947)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:4858)
	at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:342)
	at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1482)
	at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2349)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5079)
	at org.eclipse.swt.internal.win32.OS.DefWindowProc(Native Method)
	at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:512)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:4865)
	at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:342)
	at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1482)
	at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2349)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5079)
	at org.eclipse.swt.internal.win32.OS.DefWindowProc(Native Method)
	at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:512)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:4865)
	at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:342)
	at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1482)
	at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2349)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5079)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(Native Method)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3695)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1151)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1042)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:663)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:570)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:173)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:178)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:208)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:143)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:109)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:439)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:271)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:668)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:605)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1481)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1454)

Looking at the code, I can only imagine that this happened because a DPI change happened during application startup, before some of the static initializers of widgets have been processed, as there is no other way of concurrent updates of that data structure.

That is probably a rather seldom case, still something that might happen and needs to be handled.

• To fix the cause, we would probably need to ensure that the registry is fully initialized before any DPI change might be processed. This could, e.g., be achieved by registering the handler explicitly in the Display initializer instead of each control class' initializer.
• To deal with the bug, we could at least properly try to detect it and, in the worst case, throw an error, as would simply abort early application startup.