Albrecht Weinert, Fachbereich Et. & Informatik (FB3) Hochschule Bochum Zur Installation des JDK (Java Development Kit) ================================================ Inhalt ====== Welches JDK Wohin mit den Dateien des JDK Nacharbeiten zur Installation des JDK Hinzufügen von sogenannten installed extensions Registry - Eintrag für executable .jar korrigieren Installation der Java-Dokumentation (Online - Hilfe) Installation von XML - Ergänzungen Gemeinsame Installation aller Ergänzungen Gemeinsame Netzwerkeinstellungen Zum Umgang mit der JDK / JRE - Problematik Anhang: Skriptauszug zur javaDoc-Handhabung Versionsgeschichte ================== V0.00 23.08.2001 : Aus html-tools.txt und java-tips.txt ausgegl. V0.04 26.02.2002 : JDK1.4.0 (final) V0.08 14.04.2004 : JDK1.4.2_03 JDK1.5 beta V0.09 23.12.2004 : JDK1.5.0 V0.09 30.05.2005 : JDK1.5.0_03 1.4.2_07 V0.09 24.10.2005 : JDK1.5.0_04 1.4.2_09 V0.10 31.10.2005 : JavaDoc1.4 mit JDK1.5 (Hinweis) V1.03 10.06.2008 : Java 6 V.05+ 17.12.2009 : Revisionssprung wg. SVN, update V.333+ 14.09.2016 : Ganz kleine inhaltliche Änderungen Version V.1 Zuletzt geändert von A. Weinert am 23.09.2016 Copyright (c) 2008 2016 Albrecht Weinert All rights reserved. a-weinert.de Welches JDK =========== Die derzeit aktuellen Java Development Kits (JDKs) haben die Versionen 7, 8 bald auch 9 oder noch 6. Alle bis z.Z. (Sept. 2016) 9 laufen problemlos. Erprobt hier mit einigen Linux- und vielen Windows-Versionen: Windows 2003 Server / XP / 7 / 2008R2 & ... Ab JDK 1.2 wird das alles ja auch einfach "Java SDK 2" genannt und ab JDK 1.5.x "Java 5" bzw. ab JDK 1.6.x "Java 6". (Alles klar?) JDK 1.4 brachte einige echte Neuerungen: * Assertions, * neue Klassen und Interfaces, wie StringBuffer, * neue Pakete, wie java.nio, * bessere (nun integrierte) XML- Unterstützung etc. und * Geschwindigkeitsvorteile. Ein noch größerer Schritt mit vielen syntaktischen und Bibliotheksergänzungen, insbesondere noch bessere XML-Unterstützung, ist Java 5 Nun hat Java Alles, was man bisher (auch aus C++-Sicht) vielleicht vermisste -- oder besser vielleicht trotzdem nicht dazugetan hätte. Java 6 bringt Verbesserungen bei XML, JMX und Leistung. Richtig Neues brachte dann erst wieder Java 8: neue Zeit-Bibliotheken, default methods in Interfaces, lambdas etc. Manches war dann vielleicht selbst nicht so ganz verinnerlicht, sonst wäre z.B. java.time.Clock ein interface geworden. Man sollte nichts Älteres als Java 6 mehr verwenden, und eigentlich sollte man Alles auf Java8 umstellen. Das macht wegen ein paar Inkompatibilitäten zwar recht viel Arbeit, aber es lohnt wegen der neuen Möglichkeiten. Auch kann man manches alte Selbstgemachte wegwerfen, weil Java es nun endlich kann (java.time z.B.). Und übrigens: Die nun totgeschlagenen Applets werden durch Verharren bei älteren Java-Versionen nur sehr bedingt wieder lebendig. Java 9 in den early bird Versionen macht praktisch nur Ärger, wenn man schon große Projekte und laufende (java based) Server-Installationen hat. Das ist in dieser Form und Tragweite total neu, und es gibt Stimmen die fürs Überspringen von Java9 aussprechen, in etwa so wie man ja jede zweite Windows-Version ausgelassen hat. Man wird sehen. Ein paar Hinweise: 1.) Die wichtige Entwicklungsumgebung Eclipse läuft in den Versionen <= 3.0 mit Java 1.5 nur mit umständlichen Zusätzen und Einschränken. Kurz gesagt, es kommt damit gar nicht klar. Mit Eclipse 3.1 sind die Grundprobleme weg, aber mysteriöse Abstürze beim Öffnen und Schließen von (jahrelang von Vorversionen problemlos gehandhabten) Projekten kommen gelegentlich noch vor. Eclipse 3.2.0 macht keine Probleme mit 1.5 und 1.6. Aber inzwischen nimmt man ja eh Eclipse >= 4.5.2 (Mars.2) zusammen mit Java8. Mehrere Versuche mit Neon machten "keine Freude" und wurden bis dato (Sept. 2016) wieder aufgegeben. Ein bisschen scheint bei Eclipse "je höher die Version, desto bugy" zu gelten. 2.) Ein hartnäckiger Bug (der in der Vergangenheit schon kam und ging) macht JavaDoc1.5 und 1.6 (außer vielleicht für primitivste Fälle) in der Windows- Version teilweise unbrauchbar. Symptome sind mal wieder ein Schrägstrichdurcheinander und ein Absturz .... Vergessen Sie das, und nehmen Sie Java8. 3.) Der letzte und oft entscheidende Grund (gegen einen vollständigen Umstieg) nach 1.5/6 sind Inkompatibilitäten. Wenn Sie Projekte mit serialisierten Swing-Objekten haben, verbietet sich das Umstellen von 1.4 nach 1.5 ebenso, da die serialisierten Formate hier leider inkompatibel sind. Nun ja, ... siehe oben. Bei ggf. noch Umstellung von 1.4 weg mag "Zehn Schritte nach JAVA 1.5.0" Von 1.4.2 + Eclipse nach 1.5.0 + NetBeans die Sie als tojava15.pdf von hier (pub.a-weinert.de) herunterladen können, von Interesse sein. Das JDK wird von Oracle kostenlos abgegeben. Hinweis: Wenn Sie nur Java-Anwendungen verwenden aber nichts selbst entwickeln möchten, genügt Ihnen das Java runtime environment JRE. Java 9 wird diese JDK / JRE-Trennung aufgeben. Im Grunde kann man eine solche Einschränkung (JRE statt JDK) nur bei extremen Platzmangel gutheißen, da man ganz bestimmt bald eines der vielen Werkzeuge vermissen wird. Bestimmte Anwendungen, wie der Werkzeugkasten Eclipse oder der J2EE-Container Tomcat, setzen auf einem installierten JDK auf. Wenn Sie das JDK verwenden, ist die zusätzliche JRE-Installation (noch dazu in einem anderen Verzeichnis) im Allgemeinen unnötig und (im Zusammenhang mit installed extensions) schädlich und fehlerträchtig. Java9 wenn nicht gar schon höhere Versionen von Java8 werden die installed extensions beseitigen. Wenn Ihre Systeme und Serverinstallationen darauf beruhen, hören Sie rechtzeitig mit den Java updates auf, zumindest solange es kein Migrationsrezept gibt. Wohin mit den Dateien des JDK ============================= Als Zielverzeichnis der Installation und der Entpackerei der Dokumente wählen Sie am besten ein neues Unterverzeichnis ihrer Programm-Verzeichnisses -- zum Beispiel C:\util\jdk\ ***** Dies ist die Empfehlung. **** Für die meisten Fälle ist es empfehlenswert, die Versionsnummer im Verzeichnisnamen wegzulassen. Sie müssen dann auch bei Versionswechsel Betriebssystemeinstellungen nicht ändern und können auch zusätzliche Dokumentation und installed extensions einfach "stehen Lassen". Vor einer Darüber Installieren einer neuen Version sollte allerdings eine Kopie der bisherigen Installation (und dann am besten mit der Versionsnummer im Verzeichnisnamen) gemacht werden. Bei diesem Schema kann man im Bedarfsfalle ohne "Anfassen" von Systemvariablen zwischen JDK-Versionen umschalten. Wenn Sie Eclipse oder andere schlaue IDEs verwenden wollen, sollten Sie "Quellen" unbedingt mit installieren (.zip oder .jar). Nach der Installation des JDK, sprich nach der Ausführung von haben Sie dann folgende Verzeichnisstruktur (noch ohne docs): jdk _________________________|________________________________ | | | | | | | | | | README COPYRIGHT LICENSE bin lib include demo jre docs readme.html | | | | | | ____________________________________________________|________ | | | | | | | | jdom frame4j images api tooldocs relnotes guide index.html | | | | | | Nacharbeiten zur Installation des JDK ===================================== Das Verzeichnis C:\util\jdk\bin sollten Sie in Ihren Suchpfad (PATH) noch vor den Windowsverzeichnissen aber nach eventuellen Batch- oder Util-Verzeichnissen aufnehmen. Ein sinnvoller Pfad sieht beispielsweise so aus: PATH=C:\bat;C:\Programme\util;C:\programme\jdk\bin;C:\WINDOWS\system32; C:\WINDOWS;C:\WINDOWS\System32\Wbem Auf keinen Fall ist Ihr "Pfad" anders sortiert oder gar "einem Meter länger"! Die Dateien java.exe und javaw.exe löschen Sie aus dem Verzeichnis (WINNT\) System32 Ihrer Windows-Installation. (Ja, bitte. Wirklich!) Jetzt muss der Befehl java -version von jedem Verzeichnis und Laufwerk aus (in der Kommandoeingabe-Shell) laufen. Neuere Java-Versionen hängen bei der Installation ein oder zwei "Links" (ja die gibt's auch bei Windows) vorne an den Pfad. Löschen! (wenn Sie's wie oben geschildert gemacht haben. Neuere Java-Versionen löschen das ganze Installationszielverzeichnis C:\util\jdk\ (außer C:\util\jdk\docs). D.h. im Gegensatz zu früheren Versionen sind alle Ihre installed extensions weg. Vorher kopieren und nachliefern! Hinzufügen von sogenannten installed extensions =============================================== Für viele Werkzeuge, administrative Hilfen und Entwicklungen benötigen Sie das Framework Frame4J, also die neuste bzw. passende Version der Datei frame4j.jar http://weinert-automation.de/software/frame4j/frame4j.jar Sie wird einfach in das Verzeichnis C:\programme\jdk\jre\lib\ext kopiert. Noch einfacher ist gleich das Entpacken von erg.zip (http://weinert-automation.de/software/frame4j/erg.zip) im Verzeichnis der Java-Installation. Nun müssen unter einigen Anderen auch die Befehle java ShowProps java AskAlert java Update -? von jedem Verzeichnis und Laufwerk aus (in der Kommandoeingabe, "DOS- Shell" genannt) laufen. Registry - Eintrag für executable .jar korrigieren ================================================== Als ergänzende Maßnahme zu diesen und anderen "installed extensions" sollten Sie mit dem Befehl regedit nach jarfile suchen und als shell open command D:\programme\jdk\bin\javaw.exe -jar %1 %2 %3 %4 %5 %6 %7 %8 %9 (oder Verzeichnis gemäß Ihrer JDK-Installation) anstelle irgend einer abweichenden JRE-Installation (auf C:\..\Java\...) eintragen. Dies geht auch ohne RegEdit mit den Befehlen assoc und ftype. Mit assoc .class=Java-Klasse ftype Java-Klasse=runclass.bat %1 %* und der kleinen Batchdatei runclass.bat @start /i /d . /b /wait java %~n1 %2 %3 %4 %5 %6 %7 %8 %9 kann man auch Klassendateien direkt startbar machen, insbesondere wenn man die sogenannten path-extensions so setzt: PATHEXT=.COM;.EXE;.BAT;.CMD;.jar;.class Hintergrund: 1.) Der Registry-Eintrag ermöglicht das Starten grafischer, in sogenannten executable .jar-Files verpackter Java-Anwendungen mit dem gewohnten Doppelklick auf das Archiv. Außerdem lassen sich aus der Kommandoeingabe nun .jar-Dateien direkt (und mit Parameterversorgung) starten. 2.) Ohne diese kleine Maßnahme (und das o.g. Löschen der unnötigen java.exe ind javaw.exe aus System32) gibt es Probleme mit Java-Anwendungen, die installed extensions verwenden. Installation der Java-Dokumentation (Online - Hilfe) ===================================================== Gehen Sie in der Kommando-shell in das Verzeichnis C:\util\jdk\ (oder in Verzeichnis gemäß Ihrer JDK-Installation) als aktuelles Verzeichnis und erzeugen Sie mit md docs das Verzeichnis C:\util\jdk\docs\ Falls dies in einer NTFS-Partition (Windows NT) ist, sollten Sie dieses (noch leere) Verzeichnis einschließlich seiner Unterverzeichnisse komprimieren. Dies geht mit Eigenschaften im Explorer beziehungsweise mit dem Befehl compact /c /s:docs Mit dem Befehl jar xfv D:\downloads\java\jdk-xyz-doc.zip |. oder wo das Archiv ist und gemäß Ihrer Version .| entpacken Sie die JDK-Dokumentation in das Verzeichnis \jdk\docs\, wo sie hingehört. (Der Vorgang kann einige Minuten dauern und kostet ohne die o.g. Kompression des doc-Verzeichnisses etwa 60 MB mehr.) Dann entpacken Sie die Datei frame4jdoc.zip mit dem Befehl jar xfv D:\downloads\java\\frame4jdoc.zip |. oder wo das Archiv ist .| die Dokumentation des Frameworks an die richtige Stelle (für die relative "Verlinkung" der HTML-Dateien). Installation von Ergänzungen für XML, J2EE, PDF etc. ==================================================== Wenn Sie entsprechende Anwendungen nutzen (oder entwickeln) wollen, sollten Sie noch für jeweils erforderliche Dateien in Ihrem lib/ext sorgen, das dann letztlich etwa so aussehen sollte: 01.08.2016 10:57 188.024 access-bridge-64.jar 12.09.2016 17:41 305.108 aweinertbib.jar 17.03.2008 16:35 189.829 bcmail-jdk14-137.jar 17.03.2008 16:36 1.470.829 bcprov-jdk14-137.jar 01.08.2016 10:57 3.860.502 cldrdata.jar 01.08.2016 10:57 8.286 dnsns.jar 11.09.2016 16:13 530.786 frame4j.jar 27.08.2007 19:11 440.589 gwt-servlet.jar 07.04.2008 09:15 1.207.623 iText-2.0.7.jar 31.05.2013 12:54 23.876 itext-pdfa-5.4.2.jar 31.05.2013 12:53 53.711 itext-xtra-5.4.2.jar 31.05.2013 12:53 1.924.146 itextpdf-5.4.2.jar 01.08.2016 10:57 44.516 jaccess.jar 28.10.2014 18:27 571.104 javax.mail.jar 01.08.2016 10:57 18.195.218 jfxrt.jar 30.09.2011 11:43 253.160 junit-4.10.jar 31.07.2015 09:26 314.932 junit-4.12.jar 01.08.2016 10:57 2.245.827 localedata.jar 01.08.2016 10:57 1.461 meta-index 01.08.2016 10:57 2.019.024 nashorn.jar 01.12.2015 12:19 898.557 rxjava-1.0.16.jar 25.08.2013 11:16 60.866 RXTXcomm.jar 25.04.2010 18:47 110.962 saxon9-dom.jar 25.04.2010 18:49 4.740.127 saxon9.jar 01.08.2016 10:57 39.771 sunec.jar 01.08.2016 10:57 279.427 sunjce_provider.jar 01.08.2016 10:57 32.699 sunmscapi.jar 01.08.2016 10:57 250.826 sunpkcs11.jar 01.08.2016 10:57 68.924 zipfs.jar Gemeinsame Installation aller Ergänzungen ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alle bisherigen und ein paar weitere Erweiterungen sowie die zugehörige Dokumentation ergänzen Sie zu Ihrer JDK-Installation mit der passenden Datei erg.zip (http://weinert-automation.de/software/frame4j/erg.zip), indem Sie sie (siehe auch oben mit jar) in Ihrem jdk-Verzeichnis auspacken: cd /D C:\util\jdk jar xfv ......\erg.zip Damit erhalten Sie alle beschriebenen Ergänzungen, CommApi, JavaMail, BeansActivation, de.a_weinert, XSLT2 ..., incl. der zugehörigen Dokumentation in einem Arbeitsgang. Gemeinsame Netzwerkeinstellungen ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Falls Sie in einem Firmennetz hinter einem Proxy sitzen und Ihre internen und externen Netz- und Web-Zugriffe dank richtiger Einstellungen funktionieren, können Sie diese Wohltat (seit Java 5 zumindest rein theoretisch) Java-Anwendungen direkt zukommen lassen. Setzen Sie dazu den folgenden Eintrag java.net.useSystemProxies=true in der Datei C:\util\jdk\jre\lib\net.properties Im Allgemeinen wird man leider feststellen müssen, dass dies mit allen JDK/JRE für Windows von SUN nicht funktioniert. In diesem Falle muss man verbindungs- und anwendungsspezifisch die Proxy-Einstellungen setzen (wie dies alle entsprechenden Frame4J-Anwendungen tun). Oder man muss versuchen, die u.U. ja komplexen und in Firmen oft zentral vorgegebenen (proxy.pac) Einstellungen in der genannten Datei zu spiegeln (und bei jeder zentralen Änderung händisch nachzuziehen). Zum Umgang mit der JDK / JRE - Problematik ========================================== Um beispielsweise das Java-Plug-In für Mozilla-Firefox zu nutzen, kommt man i.A. nicht umhin, neben der Installation des development kit (JDK) das runtime environment (JRE) zu installieren. Dies landet dann üblicherweise in C:\programme\Java\jre6 oder ähnlich und ist mit ca. 100 Einträgen in der Registry verankert. Dies ist aus zwei Gründen ein ärgerliches Verfahren: a) Zum Einen stellt C:\programme\Java\jre6 eine Kopie von C:\util\jdk\jre dar und ist insofern reine Platzverschwendung. b) Zum Anderen bekommt die eine Installation i.A. keine Updates und nie die installed extensions der andern mit. Wenn man nicht enge Platzprobleme, wie auf manchen Uraltrechnern oder manchen Netbooks hat, ist die mit b) gegebene Inkonsistenz das eigentliche Problem. Das führt dann auch zu teilweise schwer aufzuspürenden Fehlern. Ein Weg die Inkonsistenz zu vermeiden ist ein "hartes" Kopieren von C:\util\jdk\jre nach C:\programme\Java\jre6 nach jeder Änderung, Ergänzung, Update etc. des JDK. (Letztlich gilt das auch umgekehrt, wenn man über Browser und Webstart der Installation von Ergänzungen zugestimmt hat.) Ein anderer nicht (ganz ungefährlicher) Weg ist das komplette Löschen von C:\programme\Java\jreXYZ nach der JRE-Installation und das Setzen eines "hard link" mit linkd.exe C:\Programme\Java\jreXYZ C:\util\jdk\jre Dies setzt das NTFS-Dateisystem und das Windows resource tool kit (RK) voraus. Die oben erwähnte Gefahr liegt nun darin, das man die selben Dateien nun zweimal sieht (auch Werkzeuge zur Dublettensuche) und vermeintliches Löschen einer Kopie (z.B.) ungewarnt (irgendwann) Alles vernichtet. Letztlich sind "hard links" auf Verzeichnisse unter Windows "symbolische Links" mit ziemlich unintuitivem Verhalten. Wenn man wie vorgeschlagen vorgeht, fasst man am besten keine der (scheinbaren) Dateien in C:\Programme\Java\jre6 mit normalen "Bordmitteln" an. Bestenfalls beseitigt man das symbolische Link irgendwann mal mit linkd.exe C:\Programme\Java\jre6 /D Das Mindeste was man im Explorer tun kann, um vor unbedachtes Anfassen der gelinkten Dateien zu warnen, ist dem Ordner (jre6 im Beispiel) ein anderes sehr auffälliges Symbol, wie ein rotes Stoppschild, zu geben. Aber: Da Applets und java plugins eh nicht mehr gehen, kann man aufs getrennte JRE i.A. getrost verzichten. Anhang: Skriptauszug als Anregung für die javaDoc-Handhabung ============================================================ set externalClasses=-classpath C:\Programme\Apache\Tomcat\lib\catalina.jar; C:\Programme\Apache\Tomcat\bin\tomcat-juli.jar; C:\Programme\Apache\Tomcat\lib\tomcat-coyote.jar @set jdocLaunch=javaDoc.exe -author -version -protected -J-mx96m -J-ms96m %externalClasses% -windowtitle " Frame4J -- the Java framework de.frame4j... " if not exist %JAVA_HOME%\docs\frame4j\nul md %JAVA_HOME%\docs\frame4j PushD %JAVA_HOME%\docs\frame4j java de.frame4j.Del -empty %JAVA_HOME%\docs\frame4j\ del /s /q %JAVA_HOME%\docs\frame4j\*.* @set useLinks= -link ../api if exist ..\mailapidocs set useLinks=%useLinks% -link ../mailapidocs if exist ..\servletapi set useLinks=%useLinks% -link ../servletapi if exist ..\googlegwtdocs\package-list set useLinks=%useLinks% -link ../googlegwtdocs if exist ..\tomcatapi set useLinks=%useLinks% -link ../tomcatapi @echo .%useLinks%. @echo. %jdocLaunch% %useLinks% -sourcepath %theSource%\ @%theSource%\Frame4Jdoc.list Anhang: Retten der installed extensions ======================================= Holen Sie sich Oracle's gewünschtes JDK (64 .exe) + documentation (.zip) nach D:\downloads\java8\ (beispielsweise). cd /D C:\util\ java -version -- zeigt 8_92 in diesem Anhangbeispiel ren jdk jdk8_92 md C:\util\jdk cd /D C:\util\jdk md docs compact /C /S:docs D:\downloads\java8\jdk-8u102-windows-x64.exe -- Inst.-verzeich. c:\util\jdk ! Nun löschen Sie Oracles links vom Pfad aber behalten unbedingt C:\util\jdk\bin. cd docs jar xfv D:\downloads\java8\javafx-8u102-apidocs.zip cd .. jar xfv D:\downloads\java8\jdk-8u102-docs-all.zip copy \util\jdk8_92\jre\lib\ext\frame4j.jar jre\lib\ext\ java AskAlert -- dies nur um den Erfolg mit Frame4J (pure) zu prüfen java Update -r -noreplace \util\jdk8_92\ .\ -v java ShowPorts -- und nun Frame4J (+ else + native dll)