Da null viel zu oft vorkommt, null-Referenzierungen aber vermieden werden müssen, gibt es viel Code der Art: o != null ? o : non_null_o.

Diverse Programmiersprachen bieten für dieses Konstrukt eine Abkürzung über den sogenannten null coalescing operator (Coalescing, zu Deutsch verschmelzend), der geschrieben wird mal als ?? oder als ?:, für unser Beispiel: o ?? non_null_o. Besonders hübsch ist dass bei sequenziellen Tests der Art o ?? p ?? q ?? r, wo es dann sinngemäß lautete: Liefere die erste Referenz ungleich null.

Java-Programmierer kommen nicht zu diesem Glück, können aber tricksen (http://stackoverflow.com/a/28306286/388317):

If there are only two references to test and you are using Java 8, you could use

Object o = null;
Object p = "p";
Object r = Optional.ofNullable( o ).orElse( p );
System.out.println( r );   // p

If you import static Optional the expression is not too bad.

Unfortunately your case with „several variables“ is not possible with an Optional-method. Instead you could use:

Object o = null;
Object p = null;
Object q = "p";

Optional<Object> r = Stream.of( o, p, q ).filter( Objects::nonNull ).findFirst();
System.out.println( r.get() );   // p

Es ist angeraten die Updates zu installieren:

• Java SE 8u31: http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
• Java SE 7u75/76:  http://www.oracle.com/technetwork/java/javase/downloads/index-jsp-138363.html#JDK7

Oracle stuft die Fehler als kritisch ein.

http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.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:

• 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.

• http://download.java.net/jdk9/changes/
• http://hg.openjdk.java.net/jdk9/jdk9
• http://openjdk.java.net/projects/jdk9/

Die Mailing-Listen dokumentieren weiterhin Updates:

• jdk9-dev Archives
• jdk9-all-changes Archives

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:

• JEP 110: HTTP 2 Client. Ein Ersatz für die 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.
• JEP 198: Light-Weight JSON API; für die Java EE gibt es mit der JSR 353: Java API for JSON Processingschon eine API, im Java SE wollte man nicht noch eine weitere API aufnehmen. Zudem gibt es diverse JSON-Bibliotheken.
• JEP 222: Java Read-Eval-Print Loop (REPL). Eine Art Skript-Umgebung zum interaktiven Auswerten von Anweisungen und Ausdrücken.

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.

Details unter http://weblog.ikvm.net/2014/01/16/PubliclyReportedOpenJDKVulnerabilityFixedIn7u51.aspx:

import java.lang.invoke.*;
class test extends java.io.FileOutputStream {
  static test t;
  test() throws Exception {
    super(„“);
  }
  protected void finalize() {
    t = this;
  }
  public static void main(String[] args) throws Throwable {
    MethodHandle mh = MethodHandles.lookup().findVirtual(test.class, „open“,
                        MethodType.methodType(void.class, String.class, boolean.class));
    System.out.println(mh);
    try { new test(); } catch (Exception _) { }
    System.gc();
    System.runFinalization();
    mh.invokeExact(t, „oops.txt“, false);
  }
}