Hi, For a number of reasons, I'm looking into using SubstrateVM to bundle a JavaFX application into a native executable. The SubstrateVM relies on an AOT that's more aggressive than Gluon VM and it will precompile class initializers. I clearly see the (performance) benefits of this, but it has also consequences that have to be taken into account.
One of those consequences is that threads that are somehow referenced via those class initialization code should not be in a started state. I tweaked a few initializers to avoid doing this, but the biggest impact this has so far is on Toolkit.getToolkit(). This will set the static TOOLKIT field of Toolkit to e.g. QuantumToolkit, and a whole bunch of objects become reachable including e.g. HashMap$Node hence ThreadPoolExecutor$Worker and a thread is started. As long as there is no single clinit call that uses Toolkit.getToolkit() this is not a problem, but clearly there are class initializers that use (indirectly) Toolkit.getToolkit() -- for example, AbstractMasterTimer.java has a few booleans that are statically initialized to Settings.getBoolean(), which triggers Settings.getInstance(), which uses Toolkit.getToolkit() While it is not impossible to modify those, it's probably some work and I wonder if there might be an easier solution? - Johan
