ubuntuusers.de

user unknown schrieb:

Trotzdem können wir aus dem Screenshot weder mit cut-und-paste zitieren, noch können wir diesen bei uns in Eclipse einfügen, und selbst laufen lassen, und wenn man am Antworten ist, dann hat man auch nicht mals die Miniversion des Bildes vor sich - es wäre also nett den Quellcode nachzutragen.

Gut daran habe ich jetzt nicht gedacht. Ich hab mir jetzt einfach mal den Quellcode des aller ersten, in der Schule programmierten Projekt geschnappt und ausprobiert. Gezeichnet werden soll ein Quadrat.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

import basis.*;

public class StartKlasse
{
	static Stift einStift;
	static Fenster einFenster;
	
    public static void main(String[] argv)
    {
         einFenster = new Fenster(400, 300);
         einStift    = new Stift();
         einStift.hoch();
         einStift.bewegeBis(150,150);
         einStift.runter();
         for(int i=0; i<=3; i++){
        	einStift.bewegeUm(100);
            einStift.dreheUm(90);
         }
    }
}

Dein Stift wird nirgends an das Fenster gebunden. Ohne die basis-Bibliothek zu kennen behaupte ich mal, daß das so nicht geht. Der Stift weiß gar nichts von dem Fenster, in das er zeichnen soll.

Bei der Basis-Bibliothek ist das binden des Stiftes an ein Fenster nicht nötig (ich müsste erstmal nach gucken, ob es überhaupt möglich ist, auf jeden Fall habe ich es 1,5 Jahre lang unter Windows nie gemacht und es hat geklappt).

Kann vielleicht mal jemand von euch etwas ganz simples mit swing programmieren, damit ich wirklich überprüfen kann, ob es nur an AWT scheitert.

greenmoon schrieb:

Dein Stift wird nirgends an das Fenster gebunden. Ohne die basis-Bibliothek zu kennen behaupte ich mal, daß das so nicht geht. Der Stift weiß gar nichts von dem Fenster, in das er zeichnen soll.

Bei der Basis-Bibliothek ist das binden des Stiftes an ein Fenster nicht nötig (ich müsste erstmal nach gucken, ob es überhaupt möglich ist, auf jeden Fall habe ich es 1,5 Jahre lang unter Windows nie gemacht und es hat geklappt).

Den anderen, spärlichen Fundstellen im Netz folgend scheint das tatsächlich so zu sein. Das würde die Funktion der Bibliothek sehr einschränken, wenn man immer nur in ein Fenster, oder in alle zugleich malen kann, aber aus didaktischen lassen sich die Hersteller solcher Tutorials manchmal solche Speziallösungen einfallen, die wunderbar einfach zu bedienen sind, aber gerade dadurch ein zu einfaches Bild vermitteln. Aber das ist ja jetzt nicht unsere Sorge.

Kann vielleicht mal jemand von euch etwas ganz simples mit swing programmieren, damit ich wirklich überprüfen kann, ob es nur an AWT scheitert.

Wenn man diese basis.jar irgendwo im Netz finden würde - ich finde sie nicht. So kann man sie nicht ausprobieren.

Ich hab die Bibliothek und die dazu passende Dokumentation einfach mal im Anhang hoch geladen.

javac -cp basis.jar:. StartKlasse.java 
java -cp basis.jar:. StartKlasse

Ich habe die Startklasse fehlerfrei kompilieren und ausfürhen können - sie zeichnet ein Quadrat in ein Fenster.

Das solltest Du auch in der Shell probieren (Pfad zu basis.jar gemäß Deinem System wählen). Die Konfiguration der IDE stimmt wohl nicht, und bevor man anfängt ein anderes JDK auszuprobieren, oder AWT/Swing oder Compiz verdächtigt schließt man so aus, daß es daran liegen könnte.

Deswegen ist es wichtig überhaupt ohne IDE kompilieren und Programme starten zu können.

In IDE und in der Shell sollte man außerdem unterscheiden lernen zwischen Fehlermeldungen des Kompilers (javac) und solchen der Laufzeitumgebung (JVM, JRE, java). Das Programm kompiliert bei Dir wahrscheinlich gar nicht, wenn basis.jar nicht richtig eingetragen wurde, aber das sollte man leicht erkennen (Gelbe Warndreiecke oder ähnliches, Fehlermeldung, wenn man "Run" drückt).

Schau mal in den Dokus zu eclipse, wie Du basis.jar bei Eclipse bekannt machst.

user unknown schrieb:

javac -cp basis.jar:. StartKlasse.java 
java -cp basis.jar:. StartKlasse

Ich habe die Startklasse fehlerfrei kompilieren und ausfürhen können - sie zeichnet ein Quadrat in ein Fenster.

Das solltest Du auch in der Shell probieren (Pfad zu basis.jar gemäß Deinem System wählen).

Dabei kam bei mir dann folgendes raus

marvin@Morpheus:~$ javac -cp Dokumente/Schule/Informatik/Diverses/basis.jar:. Dokumente/Schule/Informatik/Jahrgangsstufe12/Projekte/test/src/test.java
marvin@Morpheus:~$ java -cp Dokumente/Schule/Informatik/Diverses/basis.jar:. Dokumente/Schule/Informatik/Jahrgangsstufe12/Projekte/test/src/test.java
Exception in thread "main" java.lang.NoClassDefFoundError: Dokumente/Schule/Informatik/Jahrgangsstufe12/Projekte/test/src/test/java
Caused by: java.lang.ClassNotFoundException: Dokumente.Schule.Informatik.Jahrgangsstufe12.Projekte.test.src.test.java
	at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:264)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:332)
Could not find the main class: Dokumente/Schule/Informatik/Jahrgangsstufe12/Projekte/test/src/test.java. Program will exit.

Anscheinend erkennt er die main Methode nicht. Die Klasse test.java entspricht aber genau der unten geposteten StartKlasse(wobei ich nicht weiß, wieso sie verschiedene Namen haben). Auch mit dem richtig geändert Namen wie unten funktioniert es nicht [was mich aber zugegeben nicht wirklich überrascht hat]

Schau mal in den Dokus zu eclipse, wie Du basis.jar bei Eclipse bekannt machst.

Das musste ich bisher eigentlich noch nie machen, aber ich werde es trotzdem mal überprüfen.

€: was ich eigentlich am Rande noch fragen wollte: vorher hieß der Ordner bei mir Jahrgangsstufe 12, also mit Leerzeichen, das mochte das terminal aber nicht wirklich, deswegen habe ich das rausgenommen. Ich hab auch probiert, den Pfad mittels "" zu einem String zu machen (wie es unter Windows funktionierte). Wie macht man so was bei Ubuntu?

@greenmoon: Pakete in Java spiegeln sich in der Verzeichnisstruktur wieder. Du kannst den Compiler nicht einfach von irgendwo her starten. In diesem Fall muss es das Verzeichnis sein wo die Quelltext-Datei liegt, da offenbar kein package verwendet wurde.

Wenn Du bisher noch keine externe Bibliothek in Eclipse in einem Java-Projekt bekannt machen musstest, hast Du wahrscheinlich bisher noch keine externen Bibliotheken verwenden!?

greenmoon schrieb:

Anscheinend erkennt er die main Methode nicht.

Nein, er findet die Klasse nicht. Beim Aufruf von "java" musst du im Gegensatz zu "javac" Klassen angeben und keine Quellcode-Dateien. Sprich, zuerst mal muss das ".java" hinten weg. ☺

Zweitens würdest du mit diesem langen Teil ("Dokumente/Schule/Informatik/Jahrgangsstufe12/Projekte/test/src/test") Packages angeben. Heißt, Java denkt nun, dass deine Klasse namens "test" im Package "Dokumente.Schule.Informatik.Jahrgangsstufe12.Projekte.test.src" liegt, was sie wohl kaum tun wird.

Wenn du Java einen "Startpfad" mitgeben willst, dann musst du das auch mit "-cp" tun, um den Classpath zu setzen. Oder du wechselst in das Verzeichnis. Das hier wäre also äquivalent:

1

$ java -cp Dokumente/Schule/Informatik/Diverses/basis.jar:Dokumente/Schule/Informatik/Jahrgangsstufe12/Projekte/test/src test

oder

1
2

$ cd Dokumente/Schule/Informatik/Jahrgangsstufe12/Projekte/test/src
$ java -cp ~/Dokumente/Schule/Informatik/Diverses/basis.jar:. test

Vorausgesetzt natürlich, dass sich diese Pfade auf dein Home beziehen und dass die ".class"-Dateien auch immer bei den Quellcodes liegen. Wenn du's mit "javac" ohne weitere Parameter baust, dann ist letzteres so. Eclipse macht das vermutlich anders.

Die andere Frage:

€: was ich eigentlich am Rande noch fragen wollte: vorher hieß der Ordner bei mir Jahrgangsstufe 12, also mit Leerzeichen, das mochte das terminal aber nicht wirklich, deswegen habe ich das rausgenommen. Ich hab auch probiert, den Pfad mittels "" zu einem String zu machen (wie es unter Windows funktionierte). Wie macht man so was bei Ubuntu?

Tja. Genauso. 😉

Um weitere Verwirrungen (Variablennamen) zu vermeiden, verwende Single-Quotes:

1
2

$ mkdir 'Hallo Welt'
$ cd 'Hallo Welt'

Erstmal wieder vielen Dank für die ausführliche Erklärung. Am Problem hat sich aber nichts geändert. Entweder bekomme ich ein leeres Fenster oder die vorher bereits erwähnt Fehlermeldung

Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library

je nachdem, ob ich die Datei von redknight erstellt habe oder nicht.

Das heißt dann aber auch, dass es ein grundsätzliches Problem mit JAVA (oder nur AWT) sein muss und nicht an Eclipse liegt, oder?

greenmoon schrieb:

Erstmal wieder vielen Dank für die ausführliche Erklärung. Am Problem hat sich aber nichts geändert. Entweder bekomme ich ein leeres Fenster oder die vorher bereits erwähnt Fehlermeldung

Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library

1. Hast Du es in der Shell:

   • a) kompiliert

   • b) gestartet

2. Die Dokumentation gelesen, wie Du eclipse mit der basis.jar vertraut machst,

• befolgt?

3. Hast Du nicht mehr Fehlermeldung - welche library nicht gefunden wird?

je nachdem, ob ich die Datei von redknight erstellt habe oder nicht.

.gnomerc?

Das heißt dann aber auch, dass es ein grundsätzliches Problem mit JAVA (oder nur AWT) sein muss und nicht an Eclipse liegt, oder?

Nein, mit Java und AWT hat es nichts zu tun - bei mir läuft es ja mit Java und awt.

user unknown schrieb:

1. Hast Du es in der Shell:

   • a) kompiliert

   • b) gestartet

Ist das nicht genau dass, was ich vorhin gemacht habe mit dem Terminal?

2. Die Dokumentation gelesen, wie Du eclipse mit der basis.jar vertraut machst,

• befolgt?

Beim starten über das Terminal wird Eclipse doch eigentlich gar nicht gebraucht oder? Wenn es also über das Terminal auch nicht klappt kann man Eclipse doch erstmal vernachlässigen?

3. Hast Du nicht mehr Fehlermeldung - welche library nicht gefunden wird?

was ich jetzt gerade noh gefunden habe: http://forum.ubuntuusers.de/topic/can-t-load-library-usr-lib-jvm-java-6-openjdk/?highlight=can%27t#post-2428450. Das kommt mir bekannt vor und ich denk mal ich werde es probieren.

Ich habe es jetzt auch mal probiert.

In meinem Arch Linux (die Java-Umgebung (Sun Java) hier ist sauber, das steht fest) kompiliert und startet es, aber er kommt über den Punkt "new Fenster(...)" nicht hinaus, sondern verfängt sich irgendwo in einer Endlosschleife. Ich sehe dann dasselbe Bild, was du oben gepostet hast: Ein Fenster mit einem kleinen schwarzen Quadrat oben. Eine CPU ist voll ausgelastet. Das ist also ganz sicher nicht das gewünschte Ergebnis.

In einer virtuellen Maschine mit Ubuntu 9.10 und OpenJDK läuft das aber. Er zeichnet einen Kreis. Diese VM ist ziemlich "nackt", da hab ich nichts weiter dran gemacht – auch nicht das mit dem AWT_TOOLKIT. Kurios, dass es gerade in der Umgebung läuft, die deiner eigentlich viel ähnlicher sein sollte.

So. Eine Fehlersuche gestaltet sich nun aber äußerst schwierig, weil der Fehler imo in dieser ominösen "basis.jar" liegt. Oder deine Beispiele sind fehlerhaft – ich hab mich jetzt nicht komplett durch die 57 Seiten Doku gelesen. 😉 Die in der Doku aufgeführten Beispiele funktionieren ohne weitere Packages ja auch wieder nicht.

Ist der Quellcode dieser "basis.jar" irgendwo verfügbar? Wäre gut, wenn du einen Link dazu mal posten könntest. Hat das Teil vielleicht eine "Homepage"? Ansonsten fällt mir außer stumpfem Ausprobieren nicht mehr wirklich viel ein. ☹

Hier http://forum.ubuntuusers.de/post/2426853/ hat er die basis.jar gepostet.

greenmoon schrieb:

user unknown schrieb:

1. Hast Du es in der Shell:

   • a) kompiliert

   • b) gestartet

Ist das nicht genau dass, was ich vorhin gemacht habe mit dem Terminal?

Du hast ein Kommando gezeigt, welches, wie MarcBJR bemerkt hat, falsch war, und dann noch eine Fehlermeldung die aus einer Zeile besteht. Welchen Befehl Du von wo genau eingegeben hast, wie die Fehlermeldung komplett lautete - sowas kann man mit cut'n'paste einfach ins Forum posten, dann müssen wir nicht raten.

Zusätzlich ein

ls .../foo/.../basis.jar   test.class

welches zeigt, daß die Bibliothek/Klasse auch am angegebenen Pfad liegt, und so heißt wie angegeben, und wir können das Problem leichter rekonstruieren. Das Programm wurde, wenn ich das richtig sehe, lt. vorvorigem Post ja fehlerfrei kompiliert.

2. Die Dokumentation gelesen, wie Du eclipse mit der basis.jar vertraut machst,

• befolgt?

Beim starten über das Terminal wird Eclipse doch eigentlich gar nicht gebraucht oder? Wenn es also über das Terminal auch nicht klappt kann man Eclipse doch erstmal vernachlässigen?

Richtig. Dein letztes Posting macht nicht deutlich ob Du es weiterhin mit eclipse versucht hast oder nicht.

3. Hast Du nicht mehr Fehlermeldung - welche library nicht gefunden wird?

was ich jetzt gerade noh gefunden habe: http://forum.ubuntuusers.de/topic/can-t-load-library-usr-lib-jvm-java-6-openjdk/?highlight=can%27t#post-2428450. Das kommt mir bekannt vor und ich denk mal ich werde es probieren.

Den interessanten Teil der Fehlermeldung, ob eine .so-Lib fehlt, oder eine jar-Bibliothek, hast Du uns ja vorenthalten.

cd ~/Dokumente/Schule/Informatik/Jahrgangsstufe12/Projekte/test/src
ls test.class
java -cp Dokumente/Schule/Informatik/Diverses/basis.jar:. test

müßte klappen, wenn Du die test.class nicht inzwischen gelöscht hast.

user unknown schrieb:

Du hast ein Kommando gezeigt, welches, wie MarcBJR bemerkt hat, falsch war, und dann noch eine Fehlermeldung die aus einer Zeile besteht. Welchen Befehl Du von wo genau eingegeben hast, wie die Fehlermeldung komplett lautete - sowas kann man mit cut'n'paste einfach ins Forum posten, dann müssen wir nicht > raten [...] Den interessanten Teil der Fehlermeldung, ob eine .so-Lib fehlt, oder eine jar-Bibliothek, hast Du uns ja vorenthalten.

Ich habe es dann, so wie Vain beschrieben hat, nochmals wiederholt und die Fehlermeldung schon vorher ziemlich an Anfang komplett hierhin geschrieben, deswegen habe ich mich auf die "vorher bereits erwähnt Fehlermeldung" bezogen, um das ganze nicht zweimal zu posten. Wenn man das aber nicht von Anfang an verfolgt hat ist das leider nicht so deutlich gewesen befürchte ich. Deswegen jetzt hier nochmal die komlette Fehlermeldung:

Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /usr/lib/jvm/java-6-openjdk/jre/lib/i386/motif21/libmawt.so
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1646)
	at java.lang.Runtime.load0(Runtime.java:787)
	at java.lang.System.load(System.java:1022)
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1747)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1664)
	at java.lang.Runtime.loadLibrary0(Runtime.java:840)
	at java.lang.System.loadLibrary(System.java:1047)
	at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67)
	at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.awt.Toolkit.loadLibraries(Toolkit.java:1614)
	at java.awt.Toolkit.<clinit>(Toolkit.java:1636)
	at java.awt.Component.<clinit>(Component.java:568)
	at test.main(test.java:6)

Zusätzlich ein

ls .../foo/.../basis.jar   test.class

welches zeigt, daß die Bibliothek/Klasse auch am angegebenen Pfad liegt, und so heißt wie angegeben, und wir können das Problem leichter rekonstruieren. Das Programm wurde, wenn ich das richtig sehe, lt. vorvorigem Post ja fehlerfrei kompiliert.

Wenn ich das wirklich genau so eingeben sollte wird beides nicht gefunden

marvin@Morpheus:~$ ls .../foo/.../basis.jar   test.class
ls: Zugriff auf .../foo/.../basis.jar nicht möglich: No such file or directory
ls: Zugriff auf test.class nicht möglich: No such file or directory

cd ~/Dokumente/Schule/Informatik/Jahrgangsstufe12/Projekte/test/src
ls test.class
java -cp Dokumente/Schule/Informatik/Diverses/basis.jar:. test

müßte klappen, wenn Du die test.class nicht inzwischen gelöscht hast.

marvin@Morpheus:~$ cd ~/Dokumente/Schule/Informatik/Jahrgangsstufe12/Projekte/test/src
marvin@Morpheus:~/Dokumente/Schule/Informatik/Jahrgangsstufe12/Projekte/test/src$ ls test.class
test.class
marvin@Morpheus:~/Dokumente/Schule/Informatik/Jahrgangsstufe12/Projekte/test/src$ java -cp /home/marvin/Dokumente/Schule/Informatik/Diverses/basis.jar:. test

Dann kommt wieder der alte Stand, leeres Fenster mit dem schwarzen Quadrat. Ich habe jetzt auch mal auf die Prozessor Auslastung geachtet und die steigt auch bei mir stark an und bleibt auch so hoch, bis ich das Terminal wieder schließe.

Vain schrieb:

So. Eine Fehlersuche gestaltet sich nun aber äußerst schwierig, weil der Fehler imo in dieser ominösen "basis.jar" liegt. Oder deine Beispiele sind fehlerhaft – ich hab mich jetzt nicht komplett durch die 57 Seiten Doku gelesen. 😉 Die in der Doku aufgeführten Beispiele funktionieren ohne weitere Packages ja auch wieder nicht.

Ich weiß jetzt nicht genau, was du mit Fehlerhaft meinst. Das sind uralte Projekte aus dem Informatik Unterricht bei mir an der Schule, also quasi das, womit wir damals mit Java angefangen haben. Syntaktisch und Semantisch sind sie korrekt, und funktionieren auch unter dem Windows meines Dads über Eclipse.

Was ich im Bezug auf basis.jar noch interessant fände, wäre es einfach mal zwei kleine Applikation zu schreiben, einmal mit AWT und mit swing um den Fehler grundsätzlich auf die basis Bibliothek zu beschränken, bisher gehen wir alle ja nur davon aus, dass es an ihr liegt. Leider sind mir die anderen beiden Bibliotheken nicht so sehr vertraut, aus dem Unterricht kenne ich nur die basis-Bibliothek, aber ich werde mal versuchen, da was gescheitest hinzubekommen.

Ist der Quellcode dieser "basis.jar" irgendwo verfügbar? Hat das Teil vielleicht eine "Homepage"?

Wir haben die Bibliothek damals von unserem Informatiklehrer bekomme, deswegen ist mir eine Art Homepage nicht bekannt. Ich kann ihn aber mal danach fragen, irgendwo muss er das Vieh ja auch her haben.

user unknown schrieb:

Hier http://forum.ubuntuusers.de/post/2426853/ hat er die basis.jar gepostet.

Ach tschuldigung, ich vergaß, dass man Java-Bytecode ja etwas besser dekompilieren kann. (Oder lebe ich derart hinter dem Mond, dass das heute auch mit C gut geht?)

Wenn ich mir den Konstruktor der Fenster-Klasse ansehe, dann springt mir da eine Schleife in die Augen:

1
2
3
4

getToolkit().sync();
do
    info("warte");
while(!lwda);

Hmm. "info()" verweist dann auf eine Einstellung, die man setzen kann: Debug-Modus. Wenn ich den aktiviere, dann wird meine Konsole eine Weile lang mit "warte" vollgemüllt, aber schlussendlich erscheint dann das richtige Bild – ein Quadrat. Das hier funktioniert bei mir also:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

import basis.*;
import basis.vw.*;

public class StartKlasse
{
    static Stift einStift;
    static Fenster einFenster;
	
    public static void main(String[] argv)
    {
        Einstellungen.setDebugModus(true);
        einFenster = new Fenster(400, 300);
        einStift = new Stift();
        einStift.hoch();
        einStift.bewegeBis(150,150);
        einStift.runter();
        for (int i = 0; i <= 3; i++)
        {
            einStift.bewegeUm(100);
            einStift.dreheUm(90);
        }
    }
}

Lass ich das mit dem Debug-Modus weg, dann klappt es nicht mehr. Mein Fazit wäre daher, dass die basis.jar nicht wirklich sauber geschrieben ist. Die Java-Gurus hier (oder jemand, der sich mal die Mühe macht, die Threads auseinanderzuklamüsern) werden es besser erklären können, aber für mich sieht das Teil so aus, als würde die Warteschleife da das Setzen der "Statusvariablen" blockieren. Nach meinem Kenntnisstand ist Synchronisation auf diese Art sowieso völlig daneben.

Workaround für dich könnte also sein: Debug-Modus mal anschalten. 😬

Vain schrieb:

user unknown schrieb:

Hier http://forum.ubuntuusers.de/post/2426853/ hat er die basis.jar gepostet.

Ach tschuldigung, ich vergaß, dass man Java-Bytecode ja etwas besser dekompilieren kann.

Nein, ich muß mich entschuldigen. Das Den Wortteil "Quell" in "Quellcode" habe ich übersehen. Ja, sicher würde man den gerne sehen.

Lass ich das mit dem Debug-Modus weg, dann klappt es nicht mehr. Mein Fazit wäre daher, dass die basis.jar nicht wirklich sauber geschrieben ist.

Oder das OpenJDK? Bei mir klappt es nicht nur problemlos, sondern auch ohne die CPU irgendwie zu belasten. Womöglich stützt sich die basis.jar aber auf bestimmte Annahmen, die nur für das SUN-JDK gelten:

java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)

Bei dieser Meldung:

/usr/lib/jvm/java-6-openjdk/jre/lib/i386/motif21/libmawt.so
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1646)

würde ich erst mal sehen, ob die Bibliothek denn überhaupt da ist:

ls -l /usr/lib/jvm/java-6-openjdk/jre/lib/i386/motif21/libmawt.so

Bei mir ist der Pfad ein anderer:

locate libmawt 
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/headless/libmawt.so
/usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/headless/libmawt.so
/usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/motif21/libmawt.so
/usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/xawt/libmawt.so

Mit awt finde ich awt.so, mawt.so und jawt.so, ohne zu wissen was die Unterschiede sind. headless benötigt man, wenn man auf einem Server Grafikbibliotheken einsetzt, ohne daß der Server selbst im Grafikmodus liefe - das führt ohne headless-Option zu Fehlern. Die jawt isst noch kleiner, und das Sun-Zeug ist von der Größe ganz anders:

ibmux:/usr/lib/jvm/java-6-openjdk > find jre/lib/i386/ -name "*awt*" -ls 
127016    8 -rw-r--r--   1 root     root         5380 Nov 10 03:35 jre/lib/i386/libjawt.so
126995   20 -rw-r--r--   1 root     root        17940 Nov 10 03:35 jre/lib/i386/headless/libmawt.so
126999  561 -rw-r--r--   1 root     root       570500 Nov 10 03:35 jre/lib/i386/libawt.so
ibmux:/usr/lib/jvm/java-6-openjdk > locate libmawt.so 
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/headless/libmawt.so
/usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/headless/libmawt.so
/usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/motif21/libmawt.so
/usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/xawt/libmawt.so
ibmux:/usr/lib/jvm/java-6-openjdk > ls -l $(locate libmawt.so)
-rw-r--r-- 1 root root   17940 2009-11-10 03:35 /usr/lib/jvm/java-6-openjdk/jre/lib/i386/headless/libmawt.so
-rw-r--r-- 1 root root   26736 2009-07-31 15:43 /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/headless/libmawt.so
-rw-r--r-- 1 root root 3062476 2009-07-31 15:43 /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/motif21/libmawt.so
-rw-r--r-- 1 root root  353102 2009-07-31 15:43 /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/xawt/libmawt.so

und es taucht auch das motif21 auf.

Mit dem OpenJDK bekomme ich einen ähnlichen Fehler:

bin/java -cp /home/stefan/proj/mini/forum/basis.jar:/home/stefan/proj/mini/forum StartKlasse 
Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /usr/lib/jvm/java-6-openjdk/jre/lib/i386/xawt/libmawt.so

aber bei mir ist es xawt wo gesucht wird. Jetzt fehlt mir die Zeit weiterzuprobieren, ob man das openJDK so einstellen kann, daß es die anderen .so-Files nutzt, und ob das was hilft.