Java Version Verständnisfrage

[MarkusNeu]

Hallo Gemeinde,

leider verstehe ich das mit den Java-Versionen nicht.
Ich habe auf meinem Windows-Rechner Java installiert.

Jetzt prüfe ich die Java-Version: Dabei kommt folgendes:

C:\Windows\System32>java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.252-b09, mixed mode)

C:\Windows\System32>

Hier stet es 1.8 und alle reden von Java 8,9,11


Welche Java-Version verwende ich jetzt?
Danke im Voraus.

 

[MoxxiManagarm]

8

 

[Thallius]

Ich habe nie verstanden wozu man eine dreistellige Versionsnummer braucht... Ist in meinen Augen eine Unsitte. Es gibt eine Version und eine Revision. Revisionen erhöhe ich bei Bugfixes und Versionen bei neuen Features. Mehr braucht man wirklich nicht. Und wenn es denn wirklich mal eine "Version" geben sollte die so gänzlich anders ist als die Vorgängerversion, dann nenne ich die Software halt um.

 

[thecain]

Da sich SemVer etabliert hat und 3-stellig ist, bist du da wohl einer der wenigen. https://semver.org/

 

[M.L.]

Man kann ja auch mehrere (Open)JDK auf dem Rechner installieren und dann das jeweilige Verzeichnis in der Windows Pfadangabe als erstes aufführen

 

[MarkusNeu]

Vielen Dank.

Die aktuelle Schreibweise ist Quark:

Hier ist der Link von oben in DE: https://semver.org/lang/de/

Vielen Vielen Dank.

 

[kneitzel]

Wobei es auch 4-stellig Sinn machen kann aus meiner Sicht.
Neben den erwähnten 3 Zahlen hat man dann noch eine Build Nummer. Das hilft z.B. wenn ich die version 1.2.3 fertig mache. Ich baue es und stelle irgend etwas fest und baue es noch einmal ... und dann noch einmal ... und dann erneut ... Ups - jetzt existieren 4 Versionen, die alle sagen, sie seien 1.2.3 ...
Und Zeitstempel möchte man ja nicht unbedingt prüfen ...

Das ist dann das, womit man bei Microsoft konfrontiert wird. Aber der Linux Kernel neigt ja dazu, da ausufernd zu sein, da die ja auch 4 Zahlen verwenden aber dann noch ggf. ein Distributor da aktiv wird und patcht ... Aber ok, diese Frikelbude (*) muss man zum Vergleich heran ziehen, es sei denn, man braucht ein negativ-Beispiel.


(*) Frikelbude weil die einfach lachhaft vorgehen. Dieses "Vertreter Gottes auf Erden und in Kernelfragen unfehlbar" Prinzip ist einfach extrem mangelhaft und in der Geschichte haben die Verantwortlichen oft genug Quatsch gemacht. In 2.4 wurde im stable Zweig 2 oder 3 Mal das Memory-Management ausgetauscht... Aber Ihr Unvermögen haben sie ja dann eingesehen und die Verantwortung zumindest teilweise den Distributionen auf das Auge gedrückt ... Sorry, so viel ich von Linux selbst halte - von der Organisation und manchen Aussagen von Linus halte ich absolut nichts. Da könnte man sich z.B. mal bei FreeBSD umschauen, wie das Organisatorische da gelöst ist ...

 

[Thallius]

Buildnummern sind selbstverständlich haben aber absolut nichts ausserhalb der Entwicklung verloren. Deswegen gehören sie auch nicht in die Versionsnummer

 

[kneitzel]

Also ich denke, da kommen wir jetzt in Feinheiten der Definition.

Aus meiner Sicht ist die Buildnummer sehr wohl Bestandteil der Versionierung und damit der Nummer, die die genaue Version angibt (==> Versionsnummer). Und es wurde ja etwas zwischen zwei Builds geändert, daher hat man da ja auch zwei unterschiedliche Versionen.

Das diese dann in der Umgangssprache (beim "Kunden") keine Rolle spielt: ja klar.

 

[mihe7]

        <version.number>${git.commit.time}.${git.commit.id.abbrev}</version.number>

 

[Thallius]

Also ich denke, da kommen wir jetzt in Feinheiten der Definition.

Aus meiner Sicht ist die Buildnummer sehr wohl Bestandteil der Versionierung und damit der Nummer, die die genaue Version angibt (==> Versionsnummer). Und es wurde ja etwas zwischen zwei Builds geändert, daher hat man da ja auch zwei unterschiedliche Versionen.

Das diese dann in der Umgangssprache (beim "Kunden") keine Rolle spielt: ja klar.

Wenn du nicht weißt welchen Build du letztendlich an den Kunden gegeben hast (Welches eigentlich immer der letze einer Revision sein sollte) dann hast du ein Problem...

 

[kneitzel]

Wenn du nicht weißt welchen Build du letztendlich an den Kunden gegeben hast (Welches eigentlich immer der letze einer Revision sein sollte) dann hast du ein Problem...

Das ist ähnlich wie Clean Code: Wenn Du zu blöd bist, den complexen Code zu lesen, dann hast Du ein Problem!

Diese Sichtweise ist mangelhaft aus meiner Sicht. Fehler sollen vermieden werden. Also packe ich die Build Nummer richtig mit rein in die Versions-Nummer und dann ist es deutlich einfacher identifizierbar. Also so wie bei Clean Code: Da achte ich auf einen leicht lesbaren Code.

Warum soll die Identifizierbarkeit eines Builds nicht auch mit in der Version ersichtlich sein? Mit jedem Build Lauf entsteht nun einmal eine neue Version! Und diese sollte eindeutig gekennzeichnet sein.

 

[thecain]

Bei Continuous Delivery ist sowieso jeder Build ein potentieller Release. Da spricht nicht viel gegen diese Art der Versionierung

 

[mrBrown]

Die aktuelle Schreibweise ist Quark:

Hier ist der Link von oben in DE: https://semver.org/lang/de/

Welche "aktuelle Schreibweise" ist Quark?

 

[mihe7]

Welche "aktuelle Schreibweise" ist Quark?

Vermutlich die von Java.

 

[mrBrown]

Vermutlich die von Java.

Das die alte Quark war seh ich auch so, aber die aktuelle Schreibweise?

 

[temi]

leider verstehe ich das mit den Java-Versionen nicht.
Hier stet es 1.8 und alle reden von Java 8,9,11
Welche Java-Version verwende ich jetzt?

Ich kann deine Verwirrung verstehen (denn ich war ehemals genauso verwirrt). Das gilt übrigens auch für JRE, JDK, die es zudem noch von unterschiedlichen "Herstellern" gibt, wo ich mich anfangs auch gefragt habe: "Was soll ich jetzt eigentlich installieren?".