Bugzilla – Bug 157655
java from java-1_4_2-gcj-compat calls gcj
Last modified: 2006-03-17 11:23:42 UTC
etoulas@apollon:~> jdictionary Exception in thread "main" java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit at java.awt.Toolkit.getDefaultToolkit (libgcj.so.7) at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment (libgcj.so.7) at java.awt.Window.<init> (libgcj.so.7) at java.awt.Frame.<init> (libgcj.so.7) at javax.swing.JFrame.<init> (libgcj.so.7) at info.jdictionary.JDictionaryFrame.<init> (JDictionaryFrame.java:33) at info.jdictionary.JDictionary.<init> (JDictionary.java:65) at info.jdictionary.JDictionary.main (JDictionary.java:228) Caused by: java.lang.ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit at java.lang.Class.forName (libgcj.so.7) at java.lang.Class.forName (libgcj.so.7) at java.awt.Toolkit.getDefaultToolkit (libgcj.so.7) ...7 more When installing jdictionary java-1_4_2-bea is installed to by default. Another interesting thing is etoulas@apollon:~> java -version java version "1.4.2" /usr/bin/java: line 17: gcj: command not found
The bug is connected to gcj Java. However: I lowered gcj-compat priority so that bea/sun/ibm JREs will be the default java (with update-alternative mechanism) when one of those runtimes is installed as well ... right now the gcj-stuff has the same priority. With bea & sun Java it works. ... assigning to libgcj maintainer: Michael: It works with the other JREs.
Daniel: This: % java -version java version "1.4.2" /usr/bin/java: line 17: gcj: command not found is your problem though. You call gcj explicitely in the /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/bin/java script. But the java-1_4_2-gcj-compat package doesn't depend on gcj (in package gcc-java). I don't think that it should require gcc-java (because the gcj-compat package is not for developing but just for running). So the java script in it must be fixed to not call gcj, but for instance gij for the -version argument. Now the other problem with gcj not being able to load the AWT toolkit: Please someone give me a system where this happens. apollon seems to have the bea java installed menawhile. This _should_ work.
That's true, it works on apollon. You can play with my testbox odysseus (which is not in yp). On that machine I installed jdictionary which required and installed java. Feel free to use it.
Crap. These gtk classes are implemented in a different shared library, not in libgcj.so (this is okay). libgcj, when it tries to load an unknown class a.b.c tries to find files a-b-c.la and a-b-c.so to load them with dlopen. Unfortunately the normal libgcj package only contains the *.so.7* files, not the .so softlinks or the .la file, because those normally are only needed for developing. I'll include them in the libgcj package. But this doesn't actually make jdictionary work, because when I create the softlink by hand I now get this: update UI not overwritten in class: javax.swing.JLayeredPane[0,0,0x27,invalid,translucent,doublebuffered,parent=null,alignmentX=0.5,alignmentY=0.5,border=,maximumSize=java.awt.Dimension[width=32767,height=32767],minimumSize=java.awt.Dimension[width=0,height=27],preferredSize=java.awt.Dimension[width=0,height=27]] Segmentation fault This is because not everything is implemented in the AWT toolkit gtk wrapper in libgcj, so it's something which must be fixed upstream somewhen.
Fixed in Beta9.
@jsmeix: see comment #2 ... don't know if this is a known problem.
Regarding comment #6: Daniel, see https://bugzilla.novell.com/show_bug.cgi?id=155288#c2 and bug #155729 and bug #151732 starting there at the 10. comment.
Comment #2 mentioned that the command "java -version", which I think is a very reasonable command a user might want to enter doesn't work currently. Because the wrapper script calls the program "gcj", which only is available when gcc-java is installed, which isn't the case everywhere. The solution would be to make the wrapper script actually call "gij", which also is the more correct executable anyway, as "java" is the runtime interpreter, corresponding to gij, while gcj is the compiler, i.e. corresponding to javac. I'm reopening this one, changing the summary and assign it to Johannes.
Now it has become exactly bug #155729 ;-) Thanks for the explanation about "gcj" versus "gij". I will change /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/bin/java and let it call only "gij".
Fixed and submitted to STABLE. Let's see what depends on the exact output of "gcj --version" and fails now because it gets the output of "gij --version" ;-)
Created attachment 73676 [details] For your information: diff of the changea in the "java" wrapper script.