ändern neue Java Versionen was an der Programmiersprache?

[taschenrechner73]

hallo,
wir haben vor einigen Wochen in der Schule angefangen mit Java zu programmieren. Also ich kenne mich noch überhaupt nicht aus. Da ich mich parallel zum Unterricht noch einbischen weiterbilden möchte, will ich mir ein Buch kaufen. Evtl dieses hier: https://www.amazon.de/Java-von-Kopf-bis-Fuß/dp/3897214482/ref=cm_cr_arp_d_product_top?ie=UTF8
Jetzt die Frage: Das Buch scheint schon etwas älter zu sein (2006). Wenn ich jetzt mit aktuellem Java programmiere, gibt es da bedeutende Unterschiede zur Sprache oder Funktionsumfang? Sollte ich lieber ein aktuelleres Buch holen?
Vielen Dank schon mal für eure Hilfe!

 

[Joose]

Die Grundlagen werden sich nicht ändern, aber es kann immer wieder mal neue Features geben in einer Java Version.
Welche neue Features so hinzugekommen sind mit den einzelnen Versionen kannst du hier nachlesen: https://de.wikipedia.org/wiki/Java-Technologie#Versionen

Also ich würde meinen ein Buch das auf Java 6, 7 oder 8 basiert sollte dir noch ausreichend Grundlagen vermitteln und dich gut an die Sprache heranführen. Aber wenn du schon auf Amazon schaust, dann würde ich direkt schauen ein aktuelles Buch zu bekommen 😉

 

[DerShirkTV]

Hallo taschenrechner73,
Ja, es gibt Änderungen, allerdings werden (fast) immer NUR neue Dinge ergänzt und alte Dinge nicht entfernt. Es gibt da zwar auch Ausnahmen, allerdings sind diese doch sehr speziell. Meinst du mit neuen Versionen Java 7/8 oder meinst du dieses ( meiner Meinung nach blöde) Fenster mit "Java-Update verfügbar"? Ich ignoriere dieses Fenster meistens.

LG DerShirkTV

 

[mrBrown]

Meinst du mit neuen Versionen Java 7/8 oder meinst du dieses ( meiner Meinung nach blöde) Fenster mit "Java-Update verfügbar"? Ich ignoriere dieses Fenster meistens

Bugfixes und Sicherheitsupdates ignorieren ist immer ein Sinnvoller Rat...

 

[taschenrechner73]

Danke schonmal für eure Antworten!!
Ich denke ich hole mir dann einfach dieses etwas ältere Buch, da es mir einfach am besten gefällt und die Java Version ja nicht so ein riesigen Unterschied macht. Was würden ihr als Profis denn eigentlich so für ein Buch empfehlen?
LG

 

[eldrior]

Ich habe viel mit "Java ist auch nur eine Insel" gelernt. Das ist ein Open Book, das man im Internet kostenlos lesen kann und dann, wenn es einem gefällt auch erwerben kann, um die Autoren etwas zu unterstützen.

 

[JuKu]

Jetzt die Frage: Das Buch scheint schon etwas älter zu sein (2006). Wenn ich jetzt mit aktuellem Java programmiere, gibt es da bedeutende Unterschiede zur Sprache oder Funktionsumfang? Sollte ich lieber ein aktuelleres Buch holen?
Vielen Dank schon mal für eure Hilfe!

Definitiv! Auch wenn die Grundlagen lange Zeit die selben bleiben (Java 9 macht da schon wieder erste Ausnahmen und macht einige Dinge kaputt), solltest du lernen so zu programmieren, wie man es heute auch tun würde.
Was nützt es, wenn du einen uralten Standard von 2006 kannst, wo doch 2017 schon Java 9 raus kam und so viel dazu kam.

Mein Tipp:
Entweder liest du das Open Book, oder du holst dir das Java Buch "Java ist auch eine Insel", dann aber bitte gleich die neueste Version, damit du nicht mehrmals investieren musst:
https://www.amazon.de/Java-auch-ein...7402&sr=8-2&keywords=java+ist+auch+eine+insel

Ja, es gibt Änderungen, allerdings werden (fast) immer NUR neue Dinge ergänzt und alte Dinge nicht entfernt.

Falls du mit "fast" die über 1000 Klassen meinst, die in Java 9 entfernt wurden, dann lasse ich das gelten. Ansonsten ist das Quatsch. Zumal Jigsaw so viele Sachen kaputt macht, dass man viele Dinge neu schreiben müsste, wenn man jetzt überall Module verwenden wöllte.

 

[Flown]

Java 9 macht da schon wieder erste Ausnahmen und macht einige Dinge kaputt

Konkret was?

Falls du mit "fast" die über 1000 Klassen meinst, die in Java 9 entfernt wurden

Zumal Jigsaw so viele Sachen kaputt macht, dass man viele Dinge neu schreiben müsste, wenn man jetzt überall Module verwenden wöllte.

What?

 

[InfectedBytes]

Falls du mit "fast" die über 1000 Klassen meinst, die in Java 9 entfernt wurden, dann lasse ich das gelten. Ansonsten ist das Quatsch. Zumal Jigsaw so viele Sachen kaputt macht, dass man viele Dinge neu schreiben müsste, wenn man jetzt überall Module verwenden wöllte.

Wenn man schon sowas schreibt, sollte man auch Belege dafür liefern...

Falls du darauf anspielst, dass durch das Modul System nun auch endlich interne APIs geschützt sind, so ist dass die Schuld der Anwender, welche eine API benutzen, die sie gar nicht nutzen sollten, da sie eben intern ist.

 

[JuKu]

Konkret was?

Falls du schon mit Jigsaw gearbeitet hast, wird dir aufgefallen sein, dass ganz viele Libraries (z.B. auch Netty, Vertx, Spring teilweise, LWJGL und libGDX) nicht mehr ordnungsgemäß arbeiten und Fehler ausspucken, da sie durch die neuen Module im Reflection eingeschränkt sind und nicht mehr auf einige Klassen zugreifen können, die sie vormals einmal brauchten.
Ein weiteres Beispiel wäre wohl sun.misc.Unsafe, eine interne Api zum Allozieren von nativem (Off Heap) Speicher, auf welche die Libraries jetzt nicht mehr zugreifen können, sobald man Module verwendet.

Genau aus diesem Grund hatte das Java EC (Java Executive Committee, welches jede Änderung am Java Standard absegnen muss) Jigsaw auch eine Zeit lang blockiert, siehe diesen Beitrag:
http://jukusoft.com/2017/05/10/java-9-jigsaw-wurde-abgelehnt/

Auch das JaxCenter Magazin hatte darüber berichtet:
https://jaxenter.de/java-9-jigsaw-interview-56962

Oracle hat allerdings innerhalb der 30 Tage Frist reagiert und Jigsaw ein klein wenig verbessert, sodass Jigsaw dann mit 24 von 25 Stimmen durchgewunken werden konnte. Die internen Apis bleiben (nur solange man keine Module nutzt) auch unter Java 9 per Default verfügbar, mit Java 18.3 (es wird kein Java 10 geben!) wird der Zugriff dann aber gänzlich gesperrt. D.h. die Library Entwickler haben jetzt knapp ein halbes Jahr Zeit um nachzubessern, ansonsten werden ihre Libraries dann nicht mehr unter den neuen Java Versionen funktionieren. Außerdem hat Oracle das Tool jdeps herausgebracht, mit welchen man quasi alle internen Inkompatibilitäten aufdecken kann.

What?

Eine Liste aller entfernten Klassen findest du hier:
https://gunnarmorling.github.io/jdkapidiff/jdk8-jdk9-api-diff.html

Die meisten Klassen sind für den Otto-Normal-Verbraucher nicht relevant, aber wenn man mit Reflection gearbeitet hat, dann geht auch viel mehr kaputt. Das dürfte gerade Spring zum Verhängnis werden.

Zu der ganzen Thematik und den Java 9 Neuerungen gibts auf meiner Webseite übrigens auch einen Blog-Artikel:
http://jukusoft.com/2017/10/13/java-java-9-erschienen/

 

[JuKu]

Wenn man schon sowas schreibt, sollte man auch Belege dafür liefern...

Eine Liste aller entfernten Klassen (--> Belege) habe ich in dem Beitrag oben drüber bereits gebracht.

Falls du darauf anspielst, dass durch das Modul System nun auch endlich interne APIs geschützt sind, so ist dass die Schuld der Anwender, welche eine API benutzen, die sie gar nicht nutzen sollten, da sie eben intern ist.

Das ist richtig, nur ist es leider so, dass viele Libraries diese internen Apis wie sun.misc.Unsafe nun einmal brauchten, um die Performance zu erzielen, die gefordert war. LWJGL oder libGDX wären damals ohne interne Apis gar nicht möglich gewesen, da man mit On Heap Speicher & GC niemals auf solch eine Performance gekommen wäre.
Desweiteren nutzt LWJGL mit Hilfe von sun.misc.Unsafe Pointer, um die Daten nicht erst vom Java Heap in den nativen Speicher für OpenGL kopieren zu müssen. Die bekanntesten Networking Libraries in Java nutzen an irgendeiner Stelle sun.misc.Unsafe. Klar sollten sie die nie benutzen, aber sie haben damit etwas möglich gemacht, was sonst damals niemals möglich gewesen wäre. Die neue Buffer Api von Java kam sowieso erst später und selbst die bringt nicht die selbe Performance, wie sun.misc.Unsafe, obwohl da (bei Direct Buffer) nur noch die Buffer Instanz vom GC verwaltet wird.

 

[mrBrown]

Falls du schon mit Jigsaw gearbeitet hast, wird dir aufgefallen sein, dass ganz viele Libraries (z.B. auch Netty, Vertx, Spring teilweise, LWJGL und libGDX) nicht mehr ordnungsgemäß arbeiten und Fehler ausspucken, da sie durch die neuen Module im Reflection eingeschränkt sind und nicht mehr auf einige Klassen zugreifen können, die sie vormals einmal brauchten.
Ein weiteres Beispiel wäre wohl sun.misc.Unsafe, eine interne Api zum Allozieren von nativem (Off Heap) Speicher, auf welche die Libraries jetzt nicht mehr zugreifen können, sobald man Module verwendet.

Genau aus diesem Grund hatte das Java EC (Java Executive Committee, welches jede Änderung am Java Standard absegnen muss) Jigsaw auch eine Zeit lang blockiert, siehe diesem Beitrag:
http://jukusoft.com/2017/05/10/java-9-jigsaw-wurde-abgelehnt/

Auch das JaxCenter Magazin hatte darüber berichtet:
https://jaxenter.de/java-9-jigsaw-interview-56962

Oracle hat allerdings innerhalb der 30 Tage Frist reagiert und Jigsaw ein klein wenig verbessert, sodass Jigsaw dann mit 24 von 25 Stimmen durchgewunken werden konnte. Die internen Apis bleiben (nur solange man keine Module nutzt) auch unter Java 9 per Default verfügbar, mit Java 18.3 (es wird kein Java 10 geben!) wird der Zugriff dann aber gänzlich gesperrt. D.h. die Library Entwickler haben jetzt knapp ein halbes Jahr Zeit um nachzubessern, ansonsten werden ihre Libraries dann nicht mehr unter den neuen Java Versionen funktionieren. Außerdem hat Oracle das Tool jdeps herausgebracht, mit welchen man quasi alle internen Inkompatibilitäten aufdecken kann.

Wie schon mal gesagt: Alles interne Klassen die nie (und völlig zurecht) für diese Verwendung gedacht waren.

Eine Liste aller entfernten Klassen findest du hier:
https://gunnarmorling.github.io/jdkapidiff/jdk8-jdk9-api-diff.html

Eine Liste aller entfernten Klassen (--> Belege) habe ich in dem Beitrag oben drüber bereits gebracht.

Naja, nicht deine genannte 1000, sondern nicht mal 300. Und fast alle davon sind Builder für JavaFX, die schon Deprected waren.

Wie kommst du überhaupt auf 1000?
Und welche davon sind für irgendwen, der Java 8 nutzt, relevant?

Das dürfte gerade Spring zum Verhängnis werden.

Hm, Spring 5 unterstützt ganz offiziell Java 9...

 

[InfectedBytes]

...
LWJGL oder libGDX wären damals ohne interne Apis gar nicht möglich gewesen, da man mit On Heap Speicher & GC niemals auf solch eine Performance gekommen wäre.
...
Klar sollten sie die nie benutzen, aber sie haben damit etwas möglich gemacht, was sonst damals niemals möglich gewesen wäre.
...

Ähm, nein?!
Natürlich war und ist das ganze auch vollkommen ohne sun.misc.Unsafe möglich und zwar indem die Entwickler (wie vorgesehen), für solche Dinge direkt eine C Library nutzen und diese per JNI aus Java heraus nutzen.

 

[InfectedBytes]

Wenn man eine fremde API benutzt, welche nur für interne Zwecke gedacht ist, nur private constructor und singleton hat, der einzige öffentliche Zugang per Reflection sicherstellt das er nur intern benutzt wird und man somit zwangsweise per dreckigem Reflection Hack sich erst einmal eine Instanz davon holen muss, dann sollte man sich nicht wundern dass das in Zukünftigen Versionen möglicherweise nicht mehr geht.

Wenn du mit einem geklauten Schlüssel in ein fremdes Haus reingehst, würdest du dich doch auch nicht wundern wenn irgendwann einmal ein anderes Schloss in der Tür steckt. ;-)

 

[JuKu]

Ähm, nein?!
Natürlich war und ist das ganze auch vollkommen ohne sun.misc.Unsafe möglich und zwar indem die Entwickler (wie vorgesehen), für solche Dinge direkt eine C Library nutzen und diese per JNI aus Java heraus nutzen.

Gut, dass wäre für die Entwickler aber noch umständlicher gewesen.
Aber ich glaube das ist der falsche Thread, um solche Grundsatz-Diskussionen über die Verwendung von internen Apis zu führen.

 

[Flown]

Gut, dass wäre für die Entwickler aber noch umständlicher gewesen.

Wenn sich jemand hingesetzt und eine gute Lib dafür geschrieben hätte, dann gäbe es das Problem mit Unsafe nicht.

Aber ich glaube das ist der falsche Thread, um solche Grundsatz-Diskussionen über die Verwendung von internen Apis zu führen.

Ich glaube es gibt gar keine Diskussion über interne API, denn per Definition, ist sie wissentlich nicht nach außen getragen und sollte auch nicht verwendet werden.