Now that Oracle has released Java Development Kit 10, the next version, JDK 11, is just around the corner. Due in September 2018 as part of Oracle’s new six-month release cadence for the standard edition of Java, Version 11 has just a handful of announced features so far.
Java 11 is also set to lose some capabilities through the removal of CORBA and Java EE (recently renamed Jakarta EE) modules, as well as the removal of JavaFX.
Set to be a long-term support release unlike JDK 10, JDK 11 will be a reference implementation of Java Platform, Standard Edition (Java SE) 11. JDK 11 is set to receive premier-level support from Oracle until September 2023 and extended support, featuring patches and security alerts, until 2026.
New features planned for Java 11 JDK
At this point, JDK 11 is confirmed to have four new features, although more are under consideration. The planned new features include:
- HTTP Client (Standard), which standardises the incubated HTTP API client introduced in JDK 9 and updated in JDK 10. The API offers nonblocking request and response semantics through CompleteableFutures, which can be linked to trigger dependent actions. The implementation, now asynchronous, has been almost completely rewritten, after incubating in JDKs 9 and 10. The RX Flow concept has been pushed into the implementation, eliminating many custom concepts needed to support HTTP/2. Data flow now can be more easily traced, from user-level request publishers and response publishers to the underlying socket. This reduces complexity and maximises the possibility of reuse between HTTP/1 and HTTP2.
- The Epsilon garbage collector, billed as a “no-op” collector, will handle memory allocation without implementing any actual memory reclamation mechanisms. Epsilon’s use cases include testing for performance, memory pressure, and the virtual machine interface. It also could be used for short-lived jobs.
- A local-variable syntax for lambda parameters should align the syntax of a formal parameter declaration in an implicitly typed expression with the syntax of a local variable declaration. This would allow var to be used when declaring formal parameters of a implicitly typed lambda expressions.
The Java class-file format will be extended to support a new constant pool form, CONSTANT_Dynamic. The goal is to reduce the cost and disruption of developing new forms of materialisable class-file constraints.
Under consideration for Java JDK 11
The builders of Java 11 are also looking at several proposed changes or additions to JDK 11:
- Adding raw string literals to Java. This would make it easier to express character sequences in a readable form, with no Java indicators. It also would make it simpler to supply strings targeted for grammars other than Java, as well as supply strings spanning several lines of source code without supplying special indicators.
- Extending the switch statement, so it can be used as either a statement or an expression. This also would improve how switch handles nulls. These changes would simplify coding and prepare for pattern matching in switch.
- Nest-based access control, a context that aligns with the current notion of nested types in Java. Nests allow classes that are logically part of the same code entity but compiled to distinct class files to access each other’s private members without needing compilers to insert accessibility-broadening bridge methods.
Java JDK 11 drop zone
The Java EE EE and CORBA modules were deprecated in Java SE 9, with the intent to remove them in a later release — that is now set to be JDK 11.
Java SE 6, released in December 2006, had included a full web services stack for the convenience of developers—including four technologies built for the Java EE platform: JAX-WS (Java API for XML-based Web Services, JAXB (Java Architecture for XML Binding), JAF (JavaBeans Activation Framework), and Common Annotations for Java. Over time, the Java EE versions evolved, leading to difficulties in the Java SE, such as including technologies irrelevant to Java SE and more difficult maintenance across the two Java editions. With standalone versions of the Java EE technologies available from third-party sites, Oracle says there is no longer a need to have them in Java SE or in the JDK.
Still, some applications will not compile or run if they rely on out-of-the-box support in the JDK for Java EE APIs and tools. Binary and source incompatibilities would arise when migrating JDK 6, 7, or 8 to a later release. Oracle says that developers affected by these risks can deploy alternate versions of Java EE technologies instead.
CORBA dates back to the 1990s, and Oracle says that today there is no significant interest in developing modern Java applications with CORBA. And the costs of maintaining CORBA support outweigh its remaining benefits.
But the removal of CORBA risks having CORBA implementations that will not run if they include only a subset of CORBA APIs and expect the JDK to provide the remainder. There is no third-party CORBA version, and it is uncertain if a third party could take over CORBA API maintenance.
JavaFX is being removed so it is not tied to Java JDK’s twice-annual update schedule.
IDG News Service
Subscribers 0
Fans 0
Followers 0
Followers