Could not initialize class sun.awt.X11GraphicsEnvironment on Solaris

Question

I am running into this error while running my installer on a Solaris machine:

Installing...
-------------

 [==================|==================|==================|==================]
 [---Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Stack Trace:
java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11GraphicsEnvironment
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:186)
        at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102)
        at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81)
        at sun.awt.X11FontManager.isHeadless(X11FontManager.java:487)
        at sun.awt.X11FontManager.getFontPath(X11FontManager.java:767)
        at sun.font.SunFontManager.getPlatformFontPath(SunFontManager.java:3288)
        at sun.font.SunFontManager$11.run(SunFontManager.java:3314)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.font.SunFontManager.loadFonts(SunFontManager.java:3310)
        at sun.awt.X11FontManager.loadFonts(X11FontManager.java:439)
        at sun.font.SunFontManager.findFont2D(SunFontManager.java:2347)
        at sun.font.SunFontManager.findFont2D(SunFontManager.java:2285)
        at java.awt.Font.getFont2D(Font.java:498)
        at java.awt.Font.getFamily(Font.java:1187)
        at java.awt.Font.getFamily_NoClientCode(Font.java:1161)
        at java.awt.Font.getFamily(Font.java:1153)
        at ZeroGrs.a(DashoA10*..)
        at ZeroGrs.a(DashoA10*..)
        at ZeroGrs.a(DashoA10*..)
        at ZeroGrs.a(DashoA10*..)
        at ZeroGrs.a(DashoA10*..)
        at ZeroGrs.a(DashoA10*..)
        at com.zerog.ia.installer.actions.InstallUninstaller.a(DashoA10*..)
        at com.zerog.ia.installer.actions.InstallUninstaller.d(DashoA10*..)
        at com.zerog.ia.installer.actions.InstallUninstaller.installSelf(DashoA10*..)
        at com.zerog.ia.installer.InstallablePiece.install(DashoA10*..)
        at com.zerog.ia.installer.actions.InstallDirectory.install(DashoA10*..)
        at com.zerog.ia.installer.actions.InstallDirectory.install(DashoA10*..)
        at com.zerog.ia.installer.InstallablePiece.install(DashoA10*..)
        at com.zerog.ia.installer.GhostDirectory.install(DashoA10*..)
        at com.zerog.ia.installer.InstallablePiece.install(DashoA10*..)
        at com.zerog.ia.installer.Installer.install(DashoA10*..)
        at com.zerog.ia.installer.LifeCycleManager.b(DashoA10*..)
        at com.zerog.ia.installer.LifeCycleManager.a(DashoA10*..)
        at com.zerog.ia.installer.Main.main(DashoA10*..)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at com.zerog.lax.LAX.launch(DashoA10*..)
        at com.zerog.lax.LAX.main(DashoA10*..)

I tried configuring JAVA_OPTS with -Djava.awt.headless=true but it doesn't work!

Any has other solution to the issue?

Answer 1

The cause for this might be that the display variable you're using is not properly set. Run

echo $DISPLAY

and make sure the output is correct. :0 is typical for the display on the machine if it's a desktop, if it's remote it's usually a hostname or IP and number like 1.2.3.4:0 .

Depending on how in the code the existence of the DISPLAY is checked and used, you can unset it, that makes tools like Google Cloud Directory Sync continue without trying to start a graphical installer.

If that does not work for you because you need the set the proper display variable and rights (check xhost command). Start Xterm for example to see if it works.

In my case I was running the installer in docker and had to set it to the desktop IP where my docker host network was bound to :

export DISPLAY=10.11.211.211:0

After that it worked for me.

Answer 2

If the "installer" in question (which is failing with this error) may be in fact one based on install4j, note that the simple solution is to use the -c flag, so:

./myinstaller.sh

becomes:

./myinstaller.sh -c

I had the same error as mentioned originally here, and on Linux rather than Solaris, and while there are many suggestions on the web, like those here and more, I lucked out that in my case it really was a simple as adding that -c.

More here: https://www.ej-technologies.com/resources/install4j/help/doc/installers/installerModes.html#console

Answer 3

Usually, the program starts to activate the headless mode, telling the program, now you have to work in Headless mode, don't expect the hardware to help, you have to be self-reliant, relying on the computing power of the system to simulate these features:

System.setProperty("java.awt.headless","true");

Edit the ${TOMCAT_HOME}/bin/catalina.sh or ${TOMCAT_HOME}/bin/catalina.bat file:

In all similar code below:

"$_RUNJAVA" $JAVA_OPTS $CATALINA_OPTS \ 
-Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -classpath "$CLASSPATH" \ 
-Djava.security.manager \ 
-Djava.security.policy=="$CATALINA_BASE"/conf/catalina.policy \ 
-Dcatalina.base="$CATALINA_BASE" \ 
-Dcatalina.home="$CATALINA_HOME" \ 
-Djava.io.tmpdir="$CATALINA_TMPDIR" \

Add a sentence at the end:

-Djava.awt.headless=true \

The revised content is as follows:

Exec "$_RUNJAVA" $JAVA_OPTS $CATALINA_OPTS \ 
-Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -classpath "$CLASSPATH" \ 
-Dcatalina.base="$CATALINA_BASE" \ 
-Dcatalina.home="$CATALINA_HOME" \ 
-Djava.io.tmpdir="$CATALINA_TMPDIR" \ 
-Djava.awt.headless=true \

Directly search for the line -Djava.io.tmpdir="$CATALINA_TMPDIR" and add it under this line:

-Djava.awt.headless=true \

There are a total of seven places, which can be solved after the restart.

Answer 4

Solved the issue. It was my profile, where I have set my DISPLAY to one host, which is not alive. I have set it correctly and it worked.

$ export DISPLAY=

Or

$ unset DISPLAY

Answer 5

make sure you have not changed any hostname and after that this issue occured if this is the case then the problem is with hostname.

Answer 6

I had the same problem with my Linux server. I don't know what magic happened, the problem was fixed perfectly by installing Xorg on my Linux box.

sudo apt-get install xorg openbox

Answer 7

Try running this code in a constructor of a servlet

System.setProperty("java.awt.headless", "true"); 

or

Use this parameter in the startup script of the server:

-Djava.awt.headless=true

---

Here is an example of this problem documented and explaned in Apache POI when you want to create a sheet with auto size columns.

Answer 8

Actually,

-Djava.awt.headless=true

Does not fix the issue, it sidesteps it. The problem is the application you are trying to run want to run with a UI in XWindows. This error is saying the Java equivalent of 'dll not found' or '.so not found'. The library required to actually do this isn't present in the JVM classpath you are using.

The problem is you're using OpenJDK (or some other version of Java like Jikes) and the awt was one of the parts of Java that could not be open sourced for licensing reasons. So, this class doesn't exist on purpose and never will in OpenJDK

By declaring

-Djava.awt.headless=true

You are making it run in commandline mode and not all apps can do this. In your case, you got away with with. The only way to actually fix this issue is to get that class and all it's dependent classes in your classpath. The simplest way to do that is to switch to the sun JRE.