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?

score 22 · Answer 1 · edited Jun 20 '20 at 09:12

22

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`

edited Jun 20 '20 at 09:12

Community

1
1

answered Feb 21 '14 at 09:46

Deka

541
1
3
7

`export DISPLAY=` what? I could not get this. When I `echo $DISPLAY` it is `localhost:11.0`. What this is supposed to be? – Mohammad Faisal Oct 08 '18 at 13:12
1

more than the answer this [comment](https://stackoverflow.com/questions/10165761/java-cant-connect-to-x11-window-server-using-localhost10-0-as-the-value-of-t#comment56198275_15068584) helped much. – Mohammad Faisal Oct 08 '18 at 13:29
Worked for debian as well. Thx – corporateWhore Nov 12 '19 at 00:33

Edgard Leal · Answer 2 · 2016-12-15T16:39:11.163

20

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.

edited Dec 15 '16 at 16:39

answered Jan 30 '14 at 14:37

Edgard Leal

2,592
26
30

2

Perfect. Fixed my production issue I randomly got one day. I tried putting the "System.setProperty("java.awt.headless", "true");" inside the singleton application class that the Wicket Framework uses but that didn't take. So we added it to the setenv.sh which did the the trick. – eaglei22 Oct 21 '14 at 21:52

score 17 · Answer 3 · answered Dec 30 '14 at 07:48

17

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.

answered Dec 30 '14 at 07:48

Christian Bongiorno

5,150
3
38
76

https://groups.google.com/forum/#!topic/railo/49KLaaXkdrs - according to this, it could happen if native gui libs are not present and jdk is trying to use it – Kalpesh Soni Jan 26 '15 at 20:52
3

I am a Java dev of 15 years. The link you said essentially says that the JVM is trying to implement it's own rendering instead of using native libraries. This is also not true (long ago it was). This error, and the fact that it points to a SUN MICROYSTEMS specific implementation clearly and irrefutably indicates that you have a ".dll/so not found" in Java words. I suppose under the right conditions it is possible that an underlying native library failure occurred and produced this error but very unlikely. There is a special error for that: UnsatisfiedLinkError which isn't what happened here – Christian Bongiorno Jan 26 '15 at 23:04
jvm is trying to use native lib for x11 and cannot find it / instantiate it - the exact error handling will obviously depend on how sun wrote code – Kalpesh Soni Jan 27 '15 at 16:18

score 1 · Answer 4 · answered Jan 02 '18 at 22:05

1

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

answered Jan 02 '18 at 22:05

Chenhai-胡晨海

1,315
9
7

I was having the same issue while using gnome, but for some reason if I login with gnome xorg everything works as intended. – marcogmonteiro Oct 14 '19 at 14:30

score 1 · Answer 5 · answered Jan 19 '18 at 10:17

1

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.

answered Jan 19 '18 at 10:17

chinnari

11
3

That was my case. I changed my hostname and this problem started happening on Debian 6. It was resolved after logging out then logging in again. Any insights as to why it happens? – dvlcube Aug 10 '18 at 21:26

score 1 · Answer 6 · edited Oct 01 '19 at 13:10

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.

score 1 · Answer 7 · answered Oct 07 '21 at 13:16

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.

score 0 · Answer 8 · answered Oct 24 '20 at 08:36

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

Could not initialize class sun.awt.X11GraphicsEnvironment on Solaris

8 Answers8

`$ export DISPLAY=`

`$ unset DISPLAY`

Linked