Ich bin gerade dabei, von Java 8 auf Java 10 umzugsteigen.
Nach Internetrecherchen ist der mich gerade aufhaltende Umstand, dass mit Java 9 das jre-Verzeichnis im jdk-Verzeichnis verschwunden ist und damit auch der Pfad jre/lib/ext, in dem ich bislang externe Jars (z.B. für MySQL) abgelegt habe.
Es ist auf der gleichen Ebene in der jdk-10 liegt, auch ein jre-10-Verzeichnis entstanden, aber darin gibt es ebenfalls kein lib/ext-Verzeichnis.
Recht unpraktische Sache! Und eifriges Googlen im Netz zeigt nicht auf, wohin mit den externen Jars.
Ich hoffe mal, hier weiß das jemand. Wenn es daran scheitert, müsste ich auf Java 8 zurück, was keine dauerhaft sinnvolle Lösung wäre, zumal ich schon in haufenweise Quellcode Dinge ausgetauscht und getestet habe, die inzwischen als deprecated gelten.
Mir erschließt sich der Sinn nicht ganz. Wozu? Warum lieferst du die jars nicht mit deiner Software aus und für Sachen die in keinem repo liegen, du aber jars hast - sowas könntest du in einen Nexus packen und davon beziehen.
Ich übersetze den Code mit dem Compiler im JDK unter Verwendung der beiliegenden Jars. Natürlich werden die dem erzeugten Jar später auch beigelegt, aber während der Übersetzung muss ja bekannt sein, welche Klassen und Methoden es in den externen Jars gibt.
Bislang konnte man die Jars dazu im Verzeichnis jre/lib/ext unterbringen. Nun nicht mehr. Es wird wohl hoffentlich eine Alternative dazu geben…
https://www.sonatype.com/nexus-repository-sonatype
Bietet uns ein privates Maven Repo. Vereinfacht fungiert es als proxy zu maven central und zum anderen lagern wir hier code, welcher nicht über maven central verfügbar ist.
Die alternative nennt sich Maven (oder Gradle). Klingt grad so als ob du damit noch nicht gearbeitet hast. Maven sagst du einfach welche lib du in welcher Version haben möchtest und es steht dir zur Verfügung.
Nein, irgendwas zu Maven oder Gradle nützt mir nichts.
Ich verwende ein eigenes Tool, das die Jar erzeugt (und einen Haufen anderer Dinge beim Ausliefern für mich erledigt) . Ich muss nur lediglich dem JDK irgendwie die externen Jars bekanntmachen können, um die .class-Dateien erzeugen zu können.
Ich bin mir ziemlich sicher, dass maven (oder gradle) dies auch kann. Warum weichst Du da vom Standard ab? (Ich muss gestehen, ich habe schon Ewigkeiten nicht mehr den Java-Compiler direkt verwendet).
Ich glaub kaum, dass es mir zusätzlich Zip-Dateien von meinem Projekt erzeugt (in zwei Geschmacksrichtungen), diese in verschiedene Verzeichnisse sichert, das jar erzeugt und ins Zielverzeichnis kopiert, sowie dort die aufrufenden Batchdateien auf die neue Version anpasst.
Außerdem ist die Übersetzung bei mir optional.
Und selbst wenn ein anderes Tool das alles könnte bleibt die Frage, was die Alternative zum …/jre/lib/ext-Verzeichnis bei Java ab Version 9 ist. Ich kann mir nicht vorstellen, dass das ersatzlos weggefallen ist.
Es muss doch eine Möglichkeit geben, auf der Commandozeile eine Java-Datei zu übersetzen, die eine externe Jar verwendet.
Es ist relativ unüblich sich seine JRE oder das JDK mit ext libs zu patchen.
In der Regel verwaltet man seine Libs Projektbezogen.
Wenn du Eclipse nutzst, dann kannst du auf dem Projekt den Build Path konfigurieren und dort unter dem Punkt Libraries externe Jars zum Projekt hinzufügen.
Selbiges oder vergleichbares kann man auch haben indem man javac den classpath mitteilt.
Ich patche nichts. Ich liefere die externen Jars ja auch mit aus. Das JDK muss sie nur beim Vorgang des Übersetzens kennen.
Bei Eclipse mache ich das auch so, dass die externen Jars projektbezogen über “Configure Build Path” bekannt gemacht werden. Nafangs habe ich Ecplise die Jars erzeigen lassen, aber das war immer mit endlos viel Klickerei verbunden, weshalb ich mir die Arbeit erleichtert habe.
Es kann doch nicht sein, dass so etwas rudimentäres beim Übergang auf eine neue Java-Version einfach unter den Tisch fallen gelassen wird.
Nun ja, viele werden das Problem sicherlich nicht haben. Projekte setzen da halt auf Maven & Co. Was auch den Vorteil hat, dass man alles wirklich im Scope des Projektes hat und nicht erst noch die JDK-Installation anpassen muss.
Hmm … ja oder halt einfach ein batch-script. Ginge natürlich auch.
Ok, wenn das patchen ist, dann müssen andere Tools das ja auch irgendwie machen, da sonst Java Fehler wirft, wenn Methoden aufgerufen werden, die nicht bekannt sind.
jeweils noch die zum Projekt gehörigen externen Jars angeben. Da reicht vermutlich nicht ein Verzeichnis hinter -cp, sondern ich müsse alle externen Jars auflisten?
Mir wäre auch lieber, wenn man die projektspezifisch halten könnte, statt dass sich alle benötigten Jars aus allen Projekten in einem Verzeichnis tummeln.
Normalerweise reichen Verzeichnisse. Wenn ich mich nicht ganz täusche, so oft compiliert man ja nicht mehr auf der Console braucht es noch
.:PATH_TO_LIBS
Der Punkt steht für das aktuelle Verzeichnis und der Doppelpunkt trennt die verschiedenen Verzeichnisse. Weiss nur gerade nicht ob es statt dem Doppelpunkt in Windows ein Strichpunkt sein muss.
Gibt aber viel Doku wenn man nach javac und classpath googelt.
Mit Build-Tools wie Maven/Gradle, hast du einen Zentralen Ort auf deinem Rechner in welchem alle JARS landen die jemals gebraucht wurden. Im Projekt steht dann nur noch die Konfiguration zu genau den benötigten Jars, den sogenannten Dependencies.
Davor hat man in der Regel in einem Projekt einen Unterordner libs/ erstellt und dort alle Projektrelevanten jars hinzugefügt und dann diesen Ordner im cp gehabt.
Nebenbei in Maven (ist am sinnvollsten, oder?) einarbeiten
Nach und nach switchen
Möglichst alles, was mein Tool noch so tut, in Maven nachbilden, oder aber für die Jar-Ezuegung aus meinem Tool Maven aufrufen - das muss ich dann mal sehen.
Gerade pressiert es nur etwas, daher kann ich nicht direkt in ein neues Tool einsteigen.
Ich arbeite unter Windows (Vorgabe Arbeitgeber). Aber ich nehme an, dafür funktioniert Maven auch.
Gibt’s dafür ein Anleitung zum Einstieg für Neulinge?
Anmerkung: Wäre das hier eine größere Softwareschmiede, würden wir sicher alle Git und Maven und was weiß ich noch nutzen, so muss ich eigentlich alles irgendwie selbst hinfuddeln. Definitiv wäre es schlauer gewesen, damals gleich ein “richtiges” Buildtool zu nutzen, aber davon wusste ich da noch nichts. Und dann lief es ja halt immer und funktionierte.
Es ist mehr als sinnvoll maven zu kennen (glaub mir: du wirst es lieben). Gradle basiert auf maven. Der Hauptunterschied ist, dass die config dafür in Groovy geschrieben wird (gibt’s überhaupt noch andere?).
Ne ist kein Problem. funktioniert wunderbar. Arbeite hier auch auf Windows (eigener Wunsch weil Apple kacke ist hab ich mein MacBook gegen nen Windows-Laptop getauscht).
Ok das wird jetzt offtopic, ich war zwischendurch auch mal auf Apple-Geräten, aber die Firmenpolitik wurde immer seltsamer, bis ich zurück bin.
Bei allen Programmierjobs während des Studiums hab ich unter Unix gearbeitet, danach witziger Weise nur unter Windows. Ist ja letztlich auch egal, Hauptsache man bekommt die Aufgabe erledigt.
Um den Bogen zurück zu finden: Dann werde ich mich erstmal mit Maven beschäftigen. Aber zunächst bieg ich mein Tool noch soweit um, dass es mit einem eigene externen Jars-Verzeichnis und Java 10 klarkommt. Wenn das läuft… werden wir sehen, all die fachlichen Anforderungen (also die eigentlichen Aufgaben) müssen ja “nebenbei” auch noch erledigt werden.
Ich weiß nicht, ob ich das richtig verstanden habe.
Man kann sicher in den IDEs die einzubindenden externen Jar-Dateien irgendwo hinterlegen.
Ich nutze NetBeans, da kannst du externe Jars global oder für jedes Projekt einzeln die externen Jars einbinden.
Wenn du NetBeans-Nutzer bist hilft dir daher vielleicht auch folgender Wiki-Artikel: https://wiki.byte-welt.net/wiki/NetBeans_externe_Bibliotheken_bekannt_machen
Ja, das geht in Eclipse auch, habe ich auch getan, und aus Eclipse heraus funktioniert das auch alles wie es soll.
Es geht um das, was man wohl deployen nennt (?), also aus dem Projekt (und. ggf. benötigte andere Projekte) eine Jar zu erstellen (und anderes). Und hier bestand ein Problem mit dem übersetzen, wenn im Java-Code Methoden aus einer externen Jar benötigt werden.
Dies habe ich aber jetzt gelöst, ich kämpfe nur noch mit ein paar anderen Umstiegsproblemen auf Java 10. Vermutlich hätte ich Java 9 nicht überspringen sollen
Dein Problem hat nix mit einer überprungenen Java-Version gemeinsam. Du musst beim Compiler-Vorgang einfach nur die nötigen JAR’s in den Classpath packen (-cp). Bisher hast Du sie direkt in den Installationsordner vom JRE gepackt. Was aber nicht so korrekt ist.