News Oracle ändert das Versionierungs-Schema von Java

fethomm

Commander
Registriert
Okt. 2012
Beiträge
2.597
Aufgrund der sich in letzter Zeit häufenden Sicherheitsupdates für die Java-Plattform hat sich Oracle jetzt dazu entschieden, das Versionierungs-Schema der Entwicklungsumgebung zu ändern. Damit soll es in Zukunft einfacher sein, anhand der Versionsnummer zu sehen, was eine Aktualisierung beinhaltet.

Zur News: Oracle ändert das Versionierungs-Schema von Java
 
Ein wunderschönes Beispiel für "Warum einfach, wenns auch umständlich geht" :)
Nicht dass es mich bei Oracle wundern würde.
 
Auch ein wunderschönes Beispiel für "Das passiert, wenn jemand zu viel Zeit hat", wenn man letztere mit so einem Quatsch vergeuden kann. ;)
 
Ob das Release nun Features oder pure Bug-Fixes enthält, sollte dem Endanwender doch sowieso egal sein, da dieser seine Software (egal welche) ohnehin aktuell halten sollte. Zudem glaube ich auch nicht, dass sich "normale" User Changelogs durchlesen.

Für Entwickler von Java-Anwendungen ist das sicher halbwegs interessant, aber wirklich Sinn sehe ich dennoch nicht.
Wie gesagt: Software sollte eh aktuell gehalten werden. Egal ob nun Version 7u60 oder 7u59.
 
Wie wäre es wenn man Java Versionen in Zukunft einfach mit 7.16.1 betiteln würde als solch einen Käse zu fabrizieren?
 
Das es da nur so drunter und drüber geht ist echt kein Wunder.

Komplizierter gehts nicht.

Mein Vorschlag:

1.2.3

1. für die Version des Programmes.

2. Für Updates und Patches

3 für CPUs.

Bei Version 2 des Programmes einfahc mit 2.0.0 anfangen.

Am lächerlichsten ist es, eine 1 zu addieren, damit eien ungerade Versionsnummer rauskommt :D
 
Viel komplizierter wärs wohl nimma gegangen. Bin gespannt ob ich (Java-Dev) mich dran gewöhn.

Mein erster Gedanke war auch ein dickes WTF. Aber die Argumentation warum es so aussehen muss ist eigentlich ziemlich schlüssig.

Dawzon schrieb:
Wie wäre es wenn man Java Versionen in Zukunft einfach mit 7.16.1 betiteln würde als solch einen Käse zu fabrizieren?
JamesFunk schrieb:
Mein Vorschlag:
1.2.3
1. für die Version des Programmes.
2. Für Updates und Patches
3 für CPUs.
Bei Version 2 des Programmes einfahc mit 2.0.0 anfangen.
Das geht nicht, weil es Anwendungen die die Version parsen brechen würde. Also werden sie es wenn, dann mit Java 8 machen
 
Zuletzt bearbeitet:
oh man.... was kann Orcale eigentlich ausser DB?

Als Sun noch Java Chef war gab es so gut wie nie irgendwelche skandalösen Sicherheitslücken....
 
Die haben scheinbar echt Langeweile.

Warum machen die es nicht klassisch:

7.0.0 : geplante major Version
7.1.0 : geplante Update (minor)Version (mit neuen Funktionen)
7.1.1 : fix Version der Version 7.1 (Fehler und Security Updates)

Keine Buchstaben in der Version!

PS: ups...genauso wie JamesFunk hier schreibt ;)

Das Problem ist auch, dass ich viele Leute kenne, die die Updates gar nicht einspielen. Aber das ist ein generelles Problem. Besser wäre es Flash, Java und sonstig sehr updatebedürftiges über Windows Update einspielen zu lassen. Aber das auch noch MS aufhalsen?
 
Zuletzt bearbeitet:
wenn aber Montag ist, muss noch die Fakultät der gradzahl des Mond Standes hinzugefügt werden o.O
 
Oracle liefert zum besseren Verständnis ein Beispiel. Das nächste geplante Update für das JDK 7 erhält die Versionsnummer 7u40, die drei darauf eventuell folgenden CPUs würden dann mit 7u45, 7u51 und 7u55 versehen. Die nächste geplante Aktualisierung bekäme die Nummer 7u60. Die Vielfachen von 20 erlauben es außerdem, notfalls mit einer Zehner-Kadenz beispielsweise Support-Releases einzufügen, ohne die Versionierung der nachfolgenden Aktualisierungen anpassen zu müssen.

Servicepack Premium Extended Upgrade Service :freak:
 
menace_one schrieb:
wenn aber Montag ist, muss noch die Fakultät der gradzahl des Mond Standes hinzugefügt werden o.O
Eben: zudem muss jedesmal die Quersumme am Ende angehängt werden. Außer natürlich wenn der Releasetag auf einen Mittwoch fällt: dann muss von der Quersumme noch 1 abgezogen werden.
 
Gestern war ja das Thema, dass MS die Skypenachrichten überwacht hat.
Per Hash wurden da Passwörter übermittelt.

Das würde ich Java auch vorschlagen.

Diese simplen Nummerierungen in 20er Schritten für Funktionalitätsupdates sind doch langweilig.
Auch die CPUs in 5ern (wass passiert eigentlich beim 4ten CPU - dann überschreitet man eine 20er Grenze) mit ohne Gerade Zahlen sind viel zu simpel.


Ich schlage vor, dass aus den Versionsnummern Hashs errechnet:

JDK 7u40 -> 26f65dca68c77442841a52079cbfddb81acb343d

JDK 7u45 -> b502bedd67be1c87a87f1f85a7ef88c9034952e7

JDK 7u51 -> c3eaeb2d9528e631c1856cf35d24e82ed98e7d1b

...

Natürlich müsste man bei den Zahlen und Buchstaben noch irgendwelche Sonderfälle einbauen. Das mit den Montagen fände ich ganz gut.

Z.B. die Wochentage ohne Vokale dahinter.

JDK 7u40 -> 26f65dca68c77442841a52079cbfddb81acb343dMttwch

Ja das hat was.
 
SoilentGruen schrieb:
Als Sun noch Java Chef war gab es so gut wie nie irgendwelche skandalösen Sicherheitslücken....

möglicherweise weil sie nie jemand gesucht hat? Oder meinst du Oracle konnte in so kurzer Zeit so viel Sicherheitslücken einbauen? Wers glaubt :D
Interessant ist vor allem aber auch, dass Adam Gowdiak, der Finder der meisten der Java-Sicherheitslücken der letzten Zeit, Java als sehr schwer knackbar beschreibt. Aber gerade, wenn es schwer ist, wird eben das Ego geweckt noch stärker zu suchen.
 
Psst Oracle, was haltet ihr davon wenn ihr eure Zeit statt in ein Versionsschema zu investieren ihr diese Zeit darauf verwendet Java wenigstens soweit Sicher zu machen, das ich mich trau das wieder zu installieren?
 
So schlecht ist das neue Versionsschema doch nicht.
Es bricht nicht mit dem Alten, man kann aber trotzdem mehr Infos aus einer Versionsnummer ziehen.

Das einzige was mir nicht einleuchtet ist, dass für "Critical Patch Updates" (CPU) eine 5 (+1 falls gerade) addiert wird.
Somit kann man zwischen 2 geplanten Updates maximal 3 CPUs releasen, ansonsten würde sich die Versionsnummer für das nächste geplante Update verschieben.
Wieso kann addiert man für jedes CPU nicht einfach 1 (+1 falls Vielfaches von 10)?
 
Hahaha, wer sich dieses Schema hat einfallen lassen, verdient einen Orden. Hätte man nicht noch Wurzeln, Logarithmen und Fakultäten mit einbeziehen können? Hoffentlich bieten sie dann auch noch einen Versionsrechner auf ihrer Webseite an.
 
Versionsrechner? wtf?

Es ist doch ganz einfach:
Alles mit ner 0 hinten ist ein Feature Update --> z.B. 7ux0 (wobei x immer eine gerade Zahl ist)
Alles andere sind Security Patches.

Hört mal auf zu weinen.
 
Dawzon schrieb:
Wie wäre es wenn man Java Versionen in Zukunft einfach mit 7.16.1 betiteln würde als solch einen Käse zu fabrizieren?

Intern ist die Bezeichnung seit jeher...
1.<version>.0_<update>_b<buildnummer>

Dann meinte die Marketingabteilung offenbar man muss "größe Sprünge" machen und mit Java 1.5.0 hieß es dann Java 5.

Intern läuft das alte Schema aber weiter....
Also Java 7 --> 1.7.0_<update>_b<buildnummer>

Bitte Kommandozeile öffnen und "java -fullversion" eingeben:
Code:
C:\>java -fullversion
java full version "1.7.0_21-b11"

Auf der Webseite steht vermutlich "Java SE 7u21". Also "u21" ist damit die Kurzfassung von "Update 21".
 
Zurück
Oben