Dieser Artikel soll Tipps für Anpassungen und Hilfestellung bei Problemen im Umgang mit Java geben.
Unabhängig davon, ob man eine oder mehrere unterschiedliche Java-Versionen installiert hat (siehe nächster Abschnitt), liefert der folgende Befehl eine schnelle Antwort:
java -version
Eines der häufigsten Einsteigerprobleme: Bei der Installation verschiedener Java-Versionen wird möglicherweise nicht die gewünschte Version als systemweiter Standard ausgewählt. Welche Version tatsächlich gerade systemweit benutzt wird (immer nur eine!), kann mit Hilfe des Alternativen-Systems herausgefunden werden.
Für das "normale" Java (JRE):
sudo update-alternatives --config java
Für das Browser-Plugin:
sudo update-alternatives --config mozilla-javaplugin.so
Für das Entwickler-Kit (SDK):
sudo update-alternatives --config javac
Für Java Web Start:
sudo update-alternatives --config javaws
Für das IcedTea Web Control Panel (nur bei OpenJDK):
sudo update-alternatives --config itweb-settings
Nun werden die Alternativen (wenn vorhanden) nummeriert ausgegeben. Anschließend kann man durch Eingabe der entsprechenden Nummer die entsprechende Variante einstellen, die standardmäßig verwendet werden soll. Erfolgt keine Ausgabe, ist entweder Java nicht installiert oder nicht im Alternativen-System eingetragen.
Wer Oracle Java (ehemals Sun Java) manuell installiert hat, muss vor den obigen Befehlen auch einen Eintrag im Alternativen-System erstellt haben, sonst kann keine korrekte Ausgabe erfolgen.
Java unterstützt sogenannte Look and Feels (kurz LaF), mit denen das Erscheinungsbild von Programmen angepasst werden kann. Wenn einem das Standard-LaF von Java nicht gefällt, kann man ein anderes LaF zum Standard machen. Hierfür muss man die Datei swing.properties bearbeiten [2][3], deren Ort abhängig von der verwendeten Java-Version ist. Bei OpenJDK 8 findet man sie z.B. unter /etc/java-8-openjdk/swing.properties. Darin setzt man den Parameter swing.defaultlaf
mit dem kompletten Namen der Laf-Klasse. Für das plattformunabhängige Nimbus sieht die Datei dann beispielsweise so aus:
# Standard-Erscheinungsbild (Look and Feel) von Java-Anwendungen anpassen swing.defaultlaf=com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel
Je nachdem welche LaFs installiert sind, kann man Java-Programme auch an das Erscheinungsbild des Systems anpassen. Für GTK (GNOME Shell) kann das bspw. so aussehen:
# Standard-Erscheinungsbild (Look and Feel) von Java-Anwendungen anpassen swing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel
Möchte man Java-Programme an das Oxygen-Thema von KDE anpassen, kann man Joxy installieren.
Alternativ kann man beim Start eines Java-Programms das LaF dem Parameter Dswing.defaultlaf
mitgeben:
java -Dswing.defaultlaf=com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel PROGRAMM
Eine weitere Variante inklusive dem Hinweis, wie man das Schriftbild verbessern kann, ist im Artikel Schriftbild verbessern zu finden.
Man sollte zuerst die Dokumentation des Programms studieren und die Entwickler fragen, wie man mit Performance-Problemen am besten umgeht. In manchen Fällen können die folgenden Tipps sinnvoll sein - ein Wundermittel gibt es nicht.
Als Beispielaufruf sei der Befehl
java -jar meinLieblingsJavaProgramm.jar
gegeben. Auf unixoiden Systemen wird nicht automatisch die OpenGL-Beschleunigung verwendet. Um diese einzuschalten - was nur bei 2D- oder 3D-Grafikausgaben Sinn macht - verwendet man den Parameter -Dsun.java2d.opengl=true
(siehe System Properties for All Platforms / Support for Hardware-Accelerated Rendering Using OpenGL ):
java -Dsun.java2d.opengl=true -jar meinProgramm.jar
In manchen Fällen begrenzt der Speicherbedarf die Geschwindigkeit eines Programms. Die Voreinstellung für die JVM ist 64 MiB. Mehr Geschwindigkeit kann man herausholen, indem man der Anwendung mehr als die maximalen 64 MiB zur Verfügung stellt. Hierzu dient der Parameter -Xmx:
java -Xmx256m -jar meinLieblingsJavaProgramm.jar
Das hat aber nur einen Effekt, wenn das System durch häufiges Laufen der Garbage Collection belastet wird, und diese läuft nur, wenn es nötig ist. Benötigt die Anwendung weniger Speicher, so entzieht man diesen nur sinnlos dem restlichen System.
Man kann auch mehrere Optionen miteinander kombinieren:
java -Xmx256m -Dsun.java2d.opengl=true -jar mein2DProgramm.jar
Diese und weitere Parameter sind auch in den Java options erläutert.
Will man ein auf einer Webseite gefundenes Java-Applet auch offline nutzen können, ohne das dieses auf der Homepage explizit zum Download angeboten wird, hilft folgendes Vorgehen:
Die aufgerufene Webseite lokal speichern
Java-Code im Quelltext suchen. Dazu öffnet man die heruntergeladene .html-Datei mit einem Texteditor [2] und sucht den Code, der das Java-Applet aufruft. Dieser könnte in etwa so aussehen:
1 | <applet archive="../../test/jarfile1.jar, jarfile2.jar" code="Classfile1.class" width="340" height="80" vspace="0" hspace="20" align="RIGHT" > |
Die Dateien, die unter "archive="
und "code="
angeben sind, müssen nun heruntergeladen werden. Ihre Pfade sind relativ zu dem Pfad der .html-Datei angegeben, in der sich der Code für das Java-Applet befindet (Beispiel: für die Datei jarfile1.jar muss man also zwei Ordner nach oben und dann in den Unterordner test wechseln). Man ermittlet die Pfade der Dateien und gibt diese jeweils in die Adresszeile des Browsers ein. Da dieser .jar- und .class-Dateien nicht öffnen kann, werden sie zum Herunterladen angeboten. Man speichert sie alle im selben Ordner wie die .html-Datei.
Nun müssen in der .html-Datei noch die Dateipfade angepasst werden, da sich ja nun alle Dateien im selben Ordner befinden. Aus dem obigen Beispiel wird also
1 | <applet archive="jarfile1.jar, jarfile2.jar" code="Classfile1.class" width="340" height="80" vspace="0" hspace="20" align="RIGHT" > |
Danach wird die .html-Datei gespeichert und geschlossen. Anschließend kann das Applet durch Öffnen der Webseite in einem Browser gestartet werden - vorausgesetzt, ein passendes Java Browser-Plugin ist installiert.
Alternativ startet man es über den Appletviewer, der Bestandteil der Entwicklungsumgebungen (JDK) von OpenJDK 6 und 7 ist:
appletviewer Beispiel.html
Für manche Umgebungen wie z.B. Tomcat Jetty Geronimo (JSP, Servlets, JSF) muss die Umgebungsvariablen für alle Nutzer gesetzt werden. Zusätzlich muss J2SE JDK installiert sein.
Zuerst muss man nachsehen, wo der bin-Ordner von Java für javac, javadoc u.a. ist:
ls -la /etc/alternatives/javac
zum Beispiel
/etc/alternatives/javac -> /usr/lib/jvm/java-1.5.0-sun/bin/javac
Im französischen Ubuntu-Wiki befindet sich eine Tabelle mit weiteren Informationen. Nun muss die Environment-Einstellung für alle Nutzer eingestellt werden. Dafür die Datei /etc/environment in einem Editor [2] mit Root-Rechten öffnen [3] und dies eintragen:
#Pfad zum Java SDK-Basis-Ordner - kein Slash am Ende! JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun
Anschließend abmelden und neu anmelden.
Bei manchen Java-Anwendungen können Probleme mit OpenJDK auftreten (u.a. waren in der Vergangenheit ElsterOnline, die DHL-Paketmarke und aktuell immer noch Knuddels.de betroffen). Hintergrund ist meist, dass diese Programme nicht auf ihre Lauffähigkeit unter Linux getestet wurden und bestimmte (Windows-)Programme voraussetzen. Speziell bei Webanwendungen kann es aber auch am Webbrowser und/oder am jeweiligen Java-Browser-Plugin liegen. Hier half in der Vergangenheit die Verwendung von Sun Java und Firefox. Während diese Aussage hinsichtlich Firefox weiterhin ihre Gültigkeit hat, muss man ab 2012 auf Oracle Java (inkl. des Browser-Plugins) ausweichen.
Wird die Ausführung von unsignierten Java-Applets verweigert, fügt man mit dem Kontrollpanel eine Ausnahme für die jeweilige Domain hinzu. Als Beispiel kann der im Artikel Java/Oracle Java zu findende Abschnitt "Problemhebung" dienen.
Manchmal verdecken Elemente der verwendeten Desktop-Umgebung (z.B. ein Panel) das Fenster des Java-Programms. Dann verschiebt man das Fenster bei gedrückter Alt + Taste in eine andere Stelle auf dem Desktop.
In manchen Fällen kann es vorkommen, dass Java-Programme nach der Installation nicht ausgeführt werden können. Man erhält dann im Terminal nur die Nachricht:
bash: java: command not found
Dies liegt an einer fehlerhaften Verknüpfung. Um dies zu beheben, öffnet man ein Terminal [1] und legt die Verknüpfung in /usr/bin korrekt an:
sudo rm /usr/bin/java sudo ln -s /etc/alternatives/java /usr/bin/java
Danach sollte Java wieder starten.
Zwar gibt es nicht viele Fälle, aber es kommt vor, dass man ein 32-bit-Java-Programm ausführen muss, das zwingend eine 32-bit-Version von Java voraussetzt. Dies kann jedoch parallel zur 64-bit-Version erfolgen, d.h. für Java-Anwendungen, die nicht im Browser laufen, kann die 64-bit-Version weiter genutzt werden.
Daher muss auf einer 64-bit-Installation von Ubuntu zuerst eine 32-bit-Version von Java installiert werden. Nun lässt sich das auszuführende 32-bit-Javaprogramm über einen Befehl, den man im Terminal [1] eingibt oder sich z.B. als Programmstarter einrichtet, starten (die Verzeichnis-Pfade müssen entsprechend dem Installationsort der JRE und dem Programmverzeichnis angepasst werden):
/PFAD/ZU/java -jar /home/BENUTZERNAME/JAVAPROGRAMM
Die Konfiguration im Browser ist hier am Beispiel von Opera 12/Plugins gezeigt: im Menü "Tools -> Preferences -> Advanced -> Content" gibt man mit "Java options..." den Pfad der zuvor installierten Java-Version an (z.B. /home/apps/jre1.6.0_26/lib/i386) und setzt danach das Häkchen bei "Enable Java". Nach einem Neustart des Browsers sollten dann Java-Applets funktionieren.
Es kann vorkommen, dass grafische Java-Applikationen nicht korrekt dargestellt werden, wenn Desktop-Effekte (Fensterschatten, Transparenz, etc.) aktiviert sind. Die Applikation wird dabei zwar gestartet, jedoch wird außer einem leeren, grauen Fenster nichts angezeigt. Ruft man die selbe Java-Anwendung auf, wenn die Desktop-Effekte deaktiviert sind, so wird der Inhalt (Schaltflächen, Eingabefelder, usw.) einwandfrei angezeigt.
Für die Version 6 gibt es einen einfacheren Lösungsweg. Dazu öffnet man die Datei /etc/environment mithilfe eines Editors [2] mit Root-Rechten [3] und fügt am Ende der Datei die folgende Zeile hinzu:
1 | AWT_TOOLKIT="MToolkit" |
Um die Einstellung sofort zu übernehmen, kann entweder die Umgebungsvariable durch Eingabe von
export AWT_TOOLKIT="MToolkit"
gesetzt werden oder die grafische Oberfläche neu gestartet (ab- und wieder anmelden) werden.
Dieses Verfahren ist nur dann notwendig, wenn man Java nicht als fertiges Ubuntu-Paket (mit Browser-Plugin) installiert hat. Viele Java-Anwendungen im Browser benötigen die 32-Bit-Version, selbst wenn der Browser (Firefox) eine 64-Bit-Version ist.
Damit die gewünschte Java-Version benutzt werden kann, muss ein Link zu einem entsprechenden Plugin für den verwendeten Browser gesetzt werden. Möglicherweise ist noch das Plugin einer älteren/anderen Java-Version vorhanden. Daher sollte man zunächst das Plugin-Verzeichnis des Browsers überprüfen und veraltete Links löschen.
Ein Java Browser-Plugin hat immer die Endung .so (Shared Object), was bedeutet, dass dies eine Programmbibliothek ist, die sich mehrere Programme teilen können. Je nach verwendeter Java-Version (OpenJDK, Oracle Java, GNU Java) hat das Plugin einen anderen Namen und befindet sich an anderer Stelle im Dateisystem. Am leichtesten lässt sich der Speicherort mit dem folgenden Befehl im Terminal [1] herausfinden:
update-alternatives --list java
Die Ausgabe sieht dann beispielsweise so aus:
/usr/bin/gij-wrapper-4.1 /usr/lib/jvm/java-6-sun/jre/bin/java /usr/lib/j2se/1.4/bin/java
Der erste Eintrag zeigt den Pfad zu GNU-Java. Die beiden weiteren Pfade zeigen jeweils auf eine andere JVM: der zweite zeigt auf die JVM von Suns Java 6, der dritte steht für die JVM von Blackdown. Für den Browser wird aber nicht die JVM, sondern das Browser-Plugin benötigt. Am einfachsten ist es, den Befehl:
update-alternatives --list mozilla-javaplugin.so
zu verwenden oder den Dateimanager zu öffnen und hier dem angegebenen Pfad zu folgen, bis man auf das Verzeichnis plugin stößt. Hier befindet sich in der Regel die o.g. Datei. Vollständige Pfade zum Plugin kann man den unten angegebenen Befehlen entnehmen.
Möchte man nun eines der Plugins mit dem Browser Firefox verlinken, so muss man zunächst den korrekten Pfad heraussuchen und anschließend mit dem Befehl ln im Terminal [1] eine Verknüpfung zum Plugin-Verzeichnis des Browsers setzen.
OpenJDK 7
32-Bit:
sudo ln -sf /usr/lib/jvm/java-7-openjdk-i386/jre/lib/i386/IcedTeaPlugin.so /usr/lib/firefox/plugins/
64-Bit:
sudo ln -sf /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so /usr/lib/firefox/plugins/
OpenJDK 6
32-Bit:
sudo ln -sf /usr/lib/jvm/java-6-openjdk-i386/jre/lib/i386/IcedTeaPlugin.so /usr/lib/firefox/plugins/
64-Bit:
sudo ln -sf /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so /usr/lib/firefox/plugins/
32-Bit:
sudo ln -s /opt/Oracle_Java/jre1.7.0_<VERSION>/lib/i386/libnpjp2.so /usr/lib/firefox/plugins/
64-Bit:
sudo ln -s /opt/Oracle_Java/jre1.7.0_<VERSION>/lib/amd64/libnpjp2.so /usr/lib/firefox/plugins/
Dies sind natürlich nur Beispiele. Bei anderen Versionen von Java muss der Befehl angepasst werden.
Es kann vorkommen, dass eine Java-Web-Start-Anwendung zwar mit dem Java-Startbildschirm startet, dann aber nach langem Warten nur eine Fehlermeldung erscheint:
java.net.MalformedURLException: unknown protocol: ....
Dieser Fehler liegt in den Proxy-Einstellungen von Java. Um den Fehler zu beheben, muss man bei Ubuntu-Varianten mit einem Anwendungsmenü das System -> Einstellungen -> Sun Java 6 Plugin Control Center öffnen und dort in den Netzwerkeinstellungen "Direkte Verbindung" auswählen bzw. die korrekten Proxy-Einstellungen machen. Die automatische Proxy-Auswahl über den Browser funktioniert nicht.
Falls der Befehl
java -version
die folgende Ausgabe bringt
Error occurred during initialization of VM Could not reserve enough space for object heap Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.
muss in /etc/environment eine Umgebungsvariable gesetzt werden.
Dazu folgendes am Ende einfügen[1][3]:
_JAVA_OPTIONS="-Xmx500M -Xms500M"
Ein erneuter Aufruf des Befehls
java -version
sollte dann eine Ausgabe ähnlich der folgenden zeigen:
Picked up _JAVA_OPTIONS: -Xmx500M -Xms500M java version "1.7.0_55" OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1) OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
Diese Revision wurde am 8. Februar 2017 17:24 von Germrolf erstellt.