So gesagt in http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-October/005092.html:
2016/05/26 Feature Complete 2016/12/22 Feature Extension Complete 2017/01/05 Rampdown Start 2017/02/09 All Tests Run 2017/02/16 Zero Bug Bounce 2017/03/16 Rampdown Phase 2 2017/07/06 Final Release Candidate 2017/07/27 General Availability
Naja, schauen wir mal.
So sagt es Mark Reinhold http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004887.html.
Siehe http://openjdk.java.net/jeps/289 und Nachricht von Mark Reinhold.
Oracle hat angekündigt, dass das Java-Plugin für Web-Browser mit dem Erscheinen von Java 9 im nächsten Jahr nicht mehr weiterentwickelt wird.
Nachdem Mozilla Firefox und auch Google Chrome ankündigten, das Java-Plugin nicht mehr weiter unterstützen zu wollen, sind das offenbar u. a. Gründe für den Abschied vom Browser-Plugin.
Der Anteil von Java-Applets ist ohnehin kaum noch „messbar“, spätestens mit dem Java 7 Update 51, mit dem die Sicherheitsmechanismen für Java-Applets noch einmal deutlich überarbeitet wurden, sind Java-Applets in „freier Wildbahn“ kaum noch zu finden.
Oracle empfiehlt als Ersatz Java WebStart, das ohne das Plugin auskommt.
Dann ist nach aktuellen Stand Java 9 angesagt. Es verschiebt sich die Freigabe um 6 Monate. MIST! http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html
https://marketplace.eclipse.org/content/java-9-support-beta-neon. Java 9 muss installiert sein.
Wenn ein String nur aus Latin-1 Buchstaben besteht, dann kann die Zeichenfolge aus einem byte- statt einem char-Feld bestehen. Diese Änderung wurde in Java 9 nun umgesetzt: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4f6e52f9dc79. Gerade bei IDs lässt sich so 1/2 vom Speicher sparen. Und da Strings immutable sind, muss man nicht konvertieren.
Teurer wird es beim „Mischen“ wie:
String /*intern char[]*/ s = "λφα";
String /*intern char[]*/ t = " " /*intern byte[]*/
+
s /*intern char[]*/;
Intern wird hier eine inflate()-Methoden aufgerufen:
If the coder is "isLatin1", this inflates the internal 8-bit storage to 16-bit <hi=0, low> pair storage.
Für den Java 9 Compiler soll eine neue Option hinzukommen, der mit Hilfe von Meta-Daten prüft, ob ein Programm niedrigere Bibliotheken (Java 8, Java 7) nutzten soll. Details unter http://openjdk.java.net/jeps/247.
2015-12-10 Feature Complete 2016-02-04 All Tests Run 2016-02-25 Rampdown Start 2016-04-21 Zero Bug Bounce 2016-06-16 Rampdown Phase 2 2016-07-21 Final Release Candidate 2016-09-22 General Availability
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-May/002172.html
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/003295073abf zeigt uns in Java 9 endlich eine lang erwartete Methode:
+ /**
+ * Reads all bytes from this input stream and writes the bytes to the
+ * given output stream in the order that they are read. On return, this
+ * input stream will be at end of stream. This method does not close either
+ * stream.
+ * <p>
+ * This method may block indefinitely reading from the input stream, or
+ * writing to the output stream. The behavior for the case where the input
+ * and/or output stream is <i>asynchronously closed</i>, or the thread
+ * interrupted during the transfer, is highly input and output stream
+ * specific, and therefore not specified.
+ * <p>
+ * If an I/O error occurs reading from the input stream or writing to the
+ * output stream, then it may do so after some bytes have been read or
+ * written. Consequently the input stream may not be at end of stream and
+ * one, or both, streams may be in an inconsistent state. It is strongly
+ * recommended that both streams be promptly closed if an I/O error occurs.
+ *
+ * @param out the output stream, non-null
+ * @return the number of bytes transferred
+ * @throws IOException if an I/O error occurs when reading or writing
+ * @throws NullPointerException if {@code out} is {@code null}
+ *
+ * @since 1.9
+ */
+ public long transferTo(OutputStream out) throws IOException {
+ Objects.requireNonNull(out, "out");
+ long transferred = 0;
+ byte[] buffer = new byte[TRANSFER_BUFFER_SIZE];
+ int read;
+ while ((read = this.read(buffer, 0, TRANSFER_BUFFER_SIZE)) >= 0) {
+ out.write(buffer, 0, read);
+ transferred += read;
+ }
+ return transferred;
+ }
In diesem Jahr hat sich viel geklärt, was wir in Java 9 erwarten können.
Die bisher geplanten JEPs (JDK Enhancements) sind:
Wie beim Java 8 bildet das OpenJDK die Referenzimplementierung, auf deren Basis das Oracle JDK stehen wird. Das Mercurial Repository ist offen. Change-Sets der Builds dokumentieren die Änderungen.
Die Mailing-Listen dokumentieren weiterhin Updates:
Der Java-Compiler wird keinen Byte-Code mehr erzeugen von Versionen für Java 5 und Java 6. Siehe dazu auch http://www.infoq.com/news/2013/06/java-jep182.
Abgeblasen wurden:
HttpURLConnection für moderne HTTP 2.0-Anwendungen. Vielleicht abgeblasen, weil es in der Java EE schon eine REST-Client-API definiert wurde (sieheDokumentation von Jersey), und genügend Open-Source-Bibliotheken die Lücke füllen. Denkbar für Java 10 ist eine Spracherweiterung genannt Value Objects (eine Art Strukturtyp), diskutiert unter http://openjdk.java.net/jeps/169.
In der Zukunft könne es besondere Optimierungen der JVM in der Cloud bzw. in/auf einem Hypervisor geben.
Angedacht ist auch eine GPU-Beschleunigung von Java-Anwendungen. Mithttp://openjdk.java.net/projects/sumatra/ gibt es erste Lösungen.
Immer aktuell unter http://www.tutego.de/java/java-9-opendjk-9-java-se-9.html.
Das schreibt Mark Reinhold auf der Mailing-Liste: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-December/001663.html. Daraus ergeben sich eine Reihe von fundamentalen Änderungen bei den Verzeichnissen und Dateien einer JDK/JRE-Installation:
FYI, the initial changesets for JEP 220: Modular Run-Time Images [1]
were pushed just a few minutes ago. If you build JDK 9 yourself, or if
you download the next early-access build [2] (which should be available
tomorrow), you'll see all of the changes documented in JEP 220.
To summarize (please see the JEP for details):
- The "jre" subdirectory is no longer present in JDK images.
- The user-editable configuration files in the "lib" subdirectory have
been moved to the new "conf" directory.
- The endorsed-standards override mechanism has been removed.
- The extension mechanism has been removed.
- rt.jar, tools.jar, and dt.jar have been removed.
- A new URI scheme for naming stored modules, classes, and resources
has been defined.
- For tools that previously accessed rt.jar directly, a built-in NIO
file-system provider has been defined to provide access to the class
and resource files within a run-time image.
We have a few open issues to finish up, so further changes will follow
for this JEP, but none will be as disruptive as today's merge.
- Mark
[1] http://openjdk.java.net/jeps/220
[2] https://jdk9.java.net/download/
.. zumindest als EA (Early Access) auf https://jdk9.java.net/. Es sind aber noch frühe Builds, bis 2016 müssen wir noch warten.
JEP 199 http://openjdk.java.net/jeps/199 empfiehlt eine Überarbeitung des Tools sjavac, was ein “smarter” Compiler ist. Der Blogpost http://stokito.wordpress.com/tag/sjavac/ von Sergey Ponomarev beschreibt, was es mit sjava auf sich hat.