Archiv der Kategorie: Java 9

JDK 9 ist Feature Complete

So schreibt Mark Reinhold unter http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-January/005505.html:

We achieved the Feature Extension Complete milestone [1] in late
December.  All JEPs and small enhancements granted extensions [2] have
been integrated into the JDK 9 master forest.  Thanks to everyone for
all your hard work leading up to this milestone!

We're now in the first phase of the rampdown process, in which we aim to
fix the bugs that need to be fixed and understand why we're not going to
fix some bugs that perhaps ought to be fixed.  We'll use the process that
I previously proposed [3], which is now also documented under the JDK 9
Project page [4][5].

The overall feature set is, at this point, frozen.  It's highly unlikely
that any further JEPs will be targeted to the release.

Small enhancements to new features will be considered, but the bar is
now much higher.  Please request approval for such enhancements via the
existing FC-extension process [2].  Low-risk enhancements that add small
bits of missing functionality or improve usability may be approved,
especially when justified by developer feedback.  Enhancements that add
significant new functionality will require very strong justification.
Enhancements to tests or documentation do not require advance approval.

Das Ende vom Java-Plugin für Web-Browser

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.

Kompakte Strings nun in Java 9 (JEP 254)

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.

Endlich transferTo(…) im InputStream

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;
+    }

Java 9, Stand 2014

In diesem Jahr hat sich viel geklärt, was wir in Java 9 erwarten können.

Die bisher geplanten JEPs (JDK Enhancements) sind:

  • JEP 102: Process API Updates (Improve the API for controlling and managing operating-system processes.
  • JEP 143: Improve Contended Locking (Improve the performance of contended Java object monitors.
  • JEP 158: Unified JVM Logging. Introduce a common logging system for all components of the JVM.
  • JEP 165: Compiler Control. Improve the control of the JVM compilers. It will allow the user to apply sets of options depending on which method is being compiled. It also adds the possibility of changing the option sets during run time.
  • JEP 197: Segmented Code Cache. Divide the code cache into distinct segments, each of which contains compiled code of a particular type, in order to improve performance and enable future extensions.
  • JEP 198: Light-Weight JSON API. Provide a light-weight API for consuming and generating JSON documents and data streams.
  • JEP 199: Smart Java Compilation, Phase Two.. Improve the sjavac tool so that it can be used by default in the JDK build, and generalize it so that it can be used to build large projects other than the JDK.
  • JEP 201: Modular Source Code. Reorganize the JDK source code into modules, enhance the build system to compile modules, and enforce module boundaries at build time.
  • JEP 211: Elide Deprecation Warnings on Import Statements. As of Java SE 8, java compilers are required by reasonable interpretations of the Java Language Specification to issue deprecation warnings when a deprecated type is imported by name or when a deprecated member (method, field, nested type) is imported statically. These warnings are uninformative and should not be required. Deprecation warnings at actual uses of deprecated members should remain.
  • JEP 212: Resolve Lint and Doclint Warnings. The JDK code base contains numerous lint and doclint errors as reported by javac. These warnings should be resolved, at least for the fundamental parts of the platform.
  • JEP 213: Milling Project Coin. Allow @SafeVargs on private instance methods.Allow effectively-final variables to be used as resources in the try-with-resources statement. Allow diamond with inner classes if the argument type of the inferred type is denotable. Complete the removal, begun in Java SE 8, of underscore from the set of legal identifier names.
  • JEP 214: Remove GC Combinations Deprecated in JDK 8. Remove the GC combinations that were previously deprecated in JDK 8 via JEP 173.
  • JEP 216: Process Import Statements Correctly. Fix javac to properly accept and reject programs regardless of the order of import statements and extends and implements clauses.
  • JEP 219: Datagram Transport Layer Security (DTLS). Define an API for Datagram Transport Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347).
  • JEP 220: Modular Run-Time Images. Restructure the JDK and JRE run-time images to accommodate modules and to improve performance, security, and maintainability. Define a new URI scheme for naming the modules, classes, and resources stored in a run-time image without revealing the internal structure or format of the image. Revise existing specifications as required to accommodate these changes.
  • JEP 224: HTML5 Javadoc. Enhance the javadoc tool to generate HTML5 markup.
  • 228: Add More Diagnostic Commands. Define additional diagnostic commands, in order to improve the diagnosability of Hotspot and the JDK.
  • JEP 229: Create PKCS12 Keystores by Default. Transition the default keystore type from JKS to PKCS12.
  • JEP 231: Remove Launch-Time JRE Version Selection. Remove the ability to request, at JRE launch time, a version of the JRE that is not the JRE being launched.

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.

Aufgehoben/Aufgeschoben für Java 10

Abgeblasen wurden:

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.

JDK 9 Images sind nun modular

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/