Open arteymix opened 2 years ago
The workaround on our side appears to be to set AWT in headless mode. However, it would be really nice to see this addressed in JFreeChart too to completely decouple it from Swing.
In the master branch, much Swing support has moved to org.jfree.chart.swing
, but javax.swing.event.EventListenerList
is foundational. As this goes back to at least 2002, I'm curious to know if headless mode is a problem.
EventListenerList
is OK to use, the danger is to statically use UIManager.getDefaults()
and other methods that can trigger a full Swing/AWT initialization.
The culprit is JFreeChart.DEFAULT_BACKGROUND_PAINT
. It's also the only static attribute that refers to UIManager
. Why not use null
as a default and leave that to the renderer?
In this case, the panel's UI delegate relies on the UIManager
default to meet it painting burden, outlined here and here. As headless mode is a decades old feature, largely supplanting older approaches, I'm curious to know how it is a problem.
Our problem with JFreeChart.DEFAULT_BACKGROUND_PAINT initializing UIManager is that in its initialization UIManager tries to read the system's "doubleTapTime" (or something like that) which just hangs in headless mode on MacOS. Yes, this is a bug in the JVM, not in UIManager itself nor in JFreeChart, but since JFreeChart.DEFAULT_BACKGROUND_PAINT is the only thing in the whole JFreeChart that uses UIManager it would be an easy fix to just make it either null or a fixed gray color and get rid of the whole dependency on UIManager (in headless mode).
In certain circumstances, we generate plots without a graphical environment and that causes an exception to be raised when $DISPLAY is inadvertently set.
https://github.com/PavlidisLab/Gemma/issues/492