| created on | October 13, 2022 |
general availability on 2014-03-18
The original schedule aimed to ship the release in early September 2013, but due to an increased focus on browser-related security issues that date was not achievable.
| JEP | summary /remark |
|---|---|
| JEP 126: Lambda Expressions & Virtual Extension Methods | adds lambda expressions (closures) and supporting features, including method references, enhanced type inference, and virtual extension methods. |
| JEP 161: Compact Profiles | defines a few subset Profiles of the Java SE Platform Specification so that applications that do not require the entire Platform can be deployed and run on small devices. |
| JEP 174: Nashorn JavaScript Engine | implements a new lightweight, high-performance implementation of JavaScript, and integrates it into the JDK. The new engine is also available to Java applications via the existing javax.script API, and also more generally via a new command-line tool. |
| JEP 179: Document JDK API Support and Stability | there is a long-standing shortcoming in the JDK in terms of clearly specifying the support and stability usage contract for com.sun.* types and other types shipped with the JDK that are outside of the Java SE specification. These contracts and potential evolution policies should be clearly captured both in the source code of the types and in the resulting class files. |
| JEP 153: Launch JavaFX Applications | enhances the java command-line launcher to launch JavaFX applications. |
| JEP 101: Generalized Target-Type Inference | expands the scope of method type-inference to support (i) inference in method context and (ii) inference in chained calls. |
| JEP 104: Type Annotations | extends the set of annotatable locations in the syntax of the Java programming language to include names which indicate the use of a type as well as (per Java SE 5.0) the declaration of a type. |
| JEP 105: DocTree API | extends the Compiler Tree API to provide structured access to the content of javadoc comments. |
| JEP 106: Add Javadoc to javax.tools | extends the javax.tools API to provide access to javadoc. |
| JEP 118: Access to Parameter Names at Runtime | provides a mechanism to easily and reliably retrieve the parameter names of methods and constructors at runtime via core reflection. |
| JEP 120: Repeating Annotations | allows multiple application of annotations with the same type to a single program element. |
| JEP 172: DocLint | provides a means to detect errors in Javadoc comments early in the development cycle and in a way that is easily linked back to the source code. detects and reports the majority of common errors made by developers writing Javadoc comments, such that the generated output files will generally pass external validation tools, such as HTML and accessibility conformance tools. |
| JEP 103: Parallel Array Sorting | adds additional utility methods to java.util.Arrays that use the JSR 166 Fork/Join parallelism common pool to provide sorting of arrays in parallel. |
| JEP 107: Bulk Data Operations for Collections | adds functionality to the Java Collections Framework for bulk operations upon data. This is commonly referenced as “filter/map/reduce for Java.” The bulk data operations include both serial (on the calling thread) and parallel (using many threads) versions of the operations. Operations upon data are generally expressed as lambda functions. |
| JEP 109: Enhance Core Libraries with Lambda | enhances the Java core library APIs using the new lambda language feature to improve the usability and convenience of the library. |
| JEP 135: Base64 Encoding & Decoding | defines the standard API java.util.Base64 for Base64 encoding and decoding. |
| JEP 150: Date & Time API | provides a new date, time, and calendar API as a dropin replacement for the infamous Date, Calendar, and friends. The API is modeled after the well kown library Joda-Time by joda.org and offers almost the same functionality. |
| JEP 155: Concurrency Updates | scalable updatable variables, cache-oriented enhancements to the ConcurrentHashMap API, ForkJoinPool improvements, and additional Lock and Future classes. |
| JEP 170: JDBC 4.2 | minor enhancements to JDBC to improve usability and portability, including a generic setter/update method to ResultSet, PreparedStatement, and CallableStatement to support new data types such as those being defined in JSR 310. |
| JEP 177: Optimize java.text.DecimalFormat.format | optimizes java.text.DecimalFormat.format by taking advantage of numerical properties of integer and floating-point arithmetic to accelerate cases with two or three digits after the decimal point. This results in an at least 2X speedup on corresponding micro-benchmarks. |
| JEP 178: Statically-Linked JNI Libraries | enhances the JNI specification to support statically linked native libraries. This also enables developers to package a Java runtime, native application code, and Java application code together into a single binary executable that does not require the use of shared native libraries, without changes to existing Java code. |
| JEP 127: Improve Locale Data Packaging | provides a tool to generate locale data files for the runtime from the LDML format. The output file format shall be opaque so as to allow for future extensions. Provides a mechanism to package and install locale data in the form of modules. Supports some locale elements from underlying platforms. I.e., if the user preference for the date format specifies the Japanese calendar then the Java runtime should select the Japanese calendar as the default calendar. Provides a mechanism to manage the user’s locale data preference through some kind of UI, in an application (through an SPI), or at the OS level. |
| JEP 128: Unicode BCP 47 Locale Matching | defines APIs so that applications that use BCP 47 language tags (see RFC 5646) can match them to a user’s language preferences in a way that conforms to RFC 4647. |
| JEP 133: Unicode 6.2 | extends existing platform APIs to support version 6.2 of the Unicode Standard. |
| JEP 184: HTTP URL Permissions | defines a new type of network permission which grants access in terms of URLs rather than low-level IP addresses. See also API doc of java.net.URLPermission |
| JEP 113: MS-SFU Kerberos 5 Extensions | adds the MS-SFU extensions to the JDK’s Kerberos 5 implementation. |
| JEP 114: TLS Server Name Indication (SNI) Extension | adds support for the TLS Server Name Indication (SNI) Extension to allow more flexible secure virtual hosting and virtual-machine infrastructure based on SSL/TLS protocols. |
| JEP 115: AEAD CipherSuites | supports the AEAD/GCM cipher suites defined by SP-800-380D, RFC 5116, RFC 5246, RFC 5288, RFC 5289 and RFC 5430. |
| JEP 121: Stronger Algorithms for Password-Based Encryption | provides stronger Password-Based-Encryption (PBE) algorithm implementations in the SunJCE provider. |
| JEP 123: Configurable Secure Random-Number Generation | enhances the API for secure random-number generation so that it can be configured to operate within specified quality and responsiveness constraints. |
| JEP 124: Enhance the Certificate Revocation-Checking API | improves the certificate revocation-checking API to support best-effort checking, end-entity certificate checking, and mechanism-specific options and parameters. |
| JEP 129: NSA Suite B Cryptographic Algorithms | provides implementations of the cryptographic algorithms required by NSA Suite B. |
| JEP 130: SHA-224 Message Digests | implement the SHA-224 message-digest algorithm and related algorithms. |
| JEP 131: PKCS#11 Crypto Provider for 64-bit Windows | includes the SunPKCS11 provider in the JDK for 64-bit Windows. More and more vendors are providing native PKCS#11 libraries for 64-bit Windows. Shipping the SunPKCS11 provider in the JDK for 64-bit Windows will allow Java applications to use such libraries on that platform. |
| JEP 140: Limited doPrivileged | enables code to assert a subset of its privileges without otherwise preventing the full access-control stack walk to check for other permissions. |
| JEP 166: Overhaul JKS-JCEKS-PKCS12 Keystores | facilitate migrating data from JKS and JCEKS keystores by adding equivalent support to the PKCS#12 keystore. Eases the transistion from JKS and JCEKS keystores to PKCS#12 keystores. PKCS#12 is the standard keystore format of Java 8 and later. |
| JEP 185: Restrict Fetching of External XML Resources | enhances the JAXP APIs to add the ability to restrict the set of network protocols that may be used to fetch external resources in the form of DTDs, Schemas and stylesheets. |
| JEP | summary /remark |
|---|---|
| JEP 138: Autoconf-Based Build System | introduce autoconf (./configure-style) build setup, refactor the Makefiles to remove recursion; leverages JEP 139: Enhance javac to Improve Build Speed |
| JEP 160: Lambda-Form Representation for Method Handles | improves the implementation of method handles by replacing assembly language paths with an optimizable intermediate representation and then refactoring the implementation so that more work is done in portable Java code than is hardwired into the JVM. |
| JEP 162: Prepare for Modularization | undertakes changes to smooth the eventual transition to modules in a future release, provide new tools to help developers prepare for the modular platform, and deprecate certain APIs that are a significant impediment to modularization. |
| JEP 164: Leverage CPU Instructions for AES Cryptography | improves the out-of-box AES Crypto performance by using x86 AES instructions when available, and by avoiding unnecessary re-expansion of the AES key. |
| JEP 176: Mechanical Checking of Caller-Sensitive Methods | improves the security of the JDK’s method-handle implementation by replacing the existing hand-maintained list of caller-sensitive methods with a mechanism that accurately identifies such methods and allows their callers to be discovered reliably. |
| JEP 142: Reduce Cache Contention on Specified Fields | defines a way to specify that one or more fields in an object are likely to be highly contended across processor cores so that the VM can arrange for them not to share cache lines with other fields, or other objects, that are likely to be independently accessed. |
| JEP 122: Remove the Permanent Generation | removes the permanent generation from the Hotspot JVM and thus the need to tune the size of the permanent generation. |
| JEP 136: Enhanced Verification Errors | provides additional contextual information about bytecode-verification errors to ease diagnosis of bytecode or stackmap deficiencies in the field. There are tools and packages that modify bytecode for various reasons, including instrumentation and debugging. Occasionally, post-processing bytecode results in a VerifyError. Currently, the message associated with the error is rather terse and non-specific. The purpose of this feature is to expand the information available when a VerifyError occurs so that a developer can more quickly resolve the problem. |
| JEP 147: Reduce Class Metadata Footprint | reduce HotSpot’s class metadata memory footprint in order to improve performance on small devices. |
| JEP 148: Small VM | supports the creation of a small VM that is no larger than 3MB. Small devices have very strict static and dynamic memory-footprint requirements. To make Java to work well on such devices JRE’s overall static and dynamic footprint is reduced. |
| JEP 171: Fence Intrinsics | adds three memory-ordering intrinsics to the sun.misc.Unsafe class. |
| JEP 139: Enhance javac to Improve Build Speed | increases build speed by having javac use all cores and reuse javac in a server process. Simplifies work for developers by having javac build incrementally. |
| JEP 112: Charset Implementation Improvements | improves the maintainability and performance of the standard and extended charset implementations. |
| JEP 119: javax.lang.model Implementation Backed by Core Reflection | provides an implementation of the javax.lang.model.* API backed by core reflection rather than by javac. In other words, provide an alternate API to access and process the reflective information about loaded classes provided by core reflection. |
| JEP 149: Reduce Core-Library Memory Usage | reduce the dynamic memory used by core-library classes without adversely impacting performance. This increases the size of applications that can be run within a given allocation of memory for the Java runtime, allows more applications to be run with the same dynamic footprint, and increases the throughput of applications due to more efficient memory usage. |
| JEP 180: Handle Frequent HashMap Collisions with Balanced Trees | improves the performance of java.util.HashMap under high hash-collision conditions by using balanced trees rather than linked lists to store map entries. Implement the same improvement in the LinkedHashMap class. |
none
| JEP | summary /remark |
|---|---|
| JEP 117: Remove the Annotation-Processing Tool (apt) | removes the apt tool, associated API, and documentation from the JDK. The apt annotation processing framework is JDK-specific and dates back to JDK 5. The functionality of the API was standardized with JSR 269, which shipped as part of Java SE 6. In JDK 7, the entirety of the apt API was deprecated. |
Until Java 8, there was no public API for Base64 encoding and decoding. Devs often resorted to to using JDK private classes such as sun.misc.BASE64Encoder and sun.misc.BASE64Decoder.
Functionality for Base64 En/Decoding is scattered all over JDK private classes like com.sun.org.apache.xml.internal.security.utils.Base64, com.sun.net.httpserver.Base64 or java.util.prefs.Base64. A standard API allows these sorts of implementations to be retired.
Encoding and decoding is straightforward. A Base64.Encoder encoder for basic Base64 encoding can be obtained with Base64.getEncoder(). Methods for encoding accept byte arrays of byte buffers for the bytes to be encoded, and return, depending on the method, an encoded byte array, an encoded byte buffer or an encoded String, i.e.:
Example for decoding:
There are several encoders/decoders for Base64 encoding/decoding available. The methods for obtaining encoders for the various encoding methods are:
Decoders can be obtained in analogous form, i.e. with Base64.getUrlDecoder() to obtain a Base64.Decoder that decodes using the URL and Filename safe type base64 decoding scheme. The Base64.Decoder accepts all types for decoding that the Base64.Encoder encode methods may return, that is byte array, byte buffer and string.
The ConcurrentHashMap class introduces over 30 new methods, most of them leveraging the newly added streams facility and lambda expressions. These include various forEach methods:
Also, 18 reduce methods (reduce, reduceToDouble, reduceToLong etc.) and four search methods (search, searchKeys, searchValues and searchEntries) have been added.
Other miscellaneous methods like mappingCount and newKeySet have been added. This makes ConcurrentHashMaps and classes built from them now more useful as caches. The changes include methods to compute values for keys when they are not present, improved support for scanning (and possibly evicting) entries, as well as better support for maps with large numbers of elements.
Maintaining a single count, sum, etc. that is updated by possibly many threads is a common scalability problem. This small set of new classes internally employs contention-reduction techniques that provide huge throughput improvements as compared to Atomic variables. Note that this is made possible by relaxing atomicity guarantees, but in a way that is acceptable in most applications:
Exemplary for LongAdder and AtomicLong, the characteristics of the Adder classes compared to the Atomic counterparts (AtomicLong, AtomicDouble, etc.) are as follows:
Two new methods have been added to java.util.concurrent.ForkJoinPool: getCommonPoolParallelism(), which returns the targeted parallelism level of the common pool and commonPool(), which returns the common pool instance.
The new StampedLock class adds a capability-based lock with three modes for controlling read/write access (writing, reading, and optimistic reading) and with methods for conditional conversions across the three modes.
Two new interfaces have been added:
Four new classes have been added:
A crucial point of PRNG (pseudo random number generators) is balancing speed and randomness quality. Both the speed and the randomness quality depend on the source of entropy. The source of entropy in most PRNGs is environmental noise collected from user input, device drivers and other sources. The amount of noise data available to a PRNG determines both speed and quality. The higher the quality, the more noise data is required to ensure sufficient entropy and thus sufficient randomness of the delivered random numbers. If there isn’t enough entropy from available from environmental noise to generate randomness of a certain quality level, a PRNG might –depending on its characteristics– block.
I.e. on Linux systems, the pseudo file delivers a randomness of a very high quality that is sufficient for generating long term keys, but might block. On the other hand, delivers a randomness of lower a quality, that might be sufficient for applications like session keys, but doesn’t block.
On Linux, the current default configuration for SecureRandom is to obtain entropy from . SecureRandom will block if not enough data is available in the system entropy pool. The pain point on Linux systems is that apps using SecureRandom will eventually stall.
Since Java 1.2, SecureRandom.getInstance(String algorithm) can be used to obtain an instance of SecureRandom configured with a specific algorithms, but the only valid value for the algorithm string was , which is the pseudo-random number generation algorithm supplied by the SUN provider.
Java 8 introduces five new options for the configuration of the “algorithm” used in SecureRandom. I write “algorithm” in quotes here, because the five new options are the entropy source of the PRNG, not the algorithm employed in the PRNG, as one might assume from the Java API doc.
The following table lists the configure options for SecureRandom.getInstance(String algorithm):
| entropy source | description |
|---|---|
| NativePRNG | random numbers from the underlying native OS. No assertions are made as to the blocking nature of generating these numbers. |
| NativePRNGBlocking | random numbers from the underlying native OS, blocking if necessary. For example, /dev/random on UNIX-like systems. |
| NativePRNGNonBlocking | random numbers from the underlying native OS, without blocking to prevent applications from excessive stalling. For example, /dev/urandom on UNIX-like systems. |
| PKCS11 | random numbers from the underlying installed and configured PKCS11 library. |
| SHA1PRNG | pseudo-random number generation (PRNG) algorithm supplied by the SUN provider. Uses SHA-1 as the foundation of the PRNG, computes the SHA-1 hash over a true-random seed value concatenated with a 64-bit counter which is incremented by 1 for each operation. From the 160-bit SHA-1 output, only 64 bits are used. |
| Windows-PRNG | random numbers from the underlying Windows OS. |
OpenJDK, JDK 8
OpenJDK, JDK 8 Features
Java™ Platform Standard Ed. 8 API Documentation, java.util.Base64 API
Java™ Platform Standard Ed. 8 API Documentation, java.util.Base64.Encoder API
Java™ Platform Standard Ed. 8 API Documentation, java.util.Base64.Decoder API
Oracle Java Documentation, Concurrency Utilities Enhancements in Java SE 8
Java™ Platform Standard Ed. 8 API Documentation, java.util.concurrent.atomic.LongAdder API
Java™ Platform Standard Ed. 8 API Documentation, java.util.concurrent.atomic.AtomicLong API
Java™ Platform Standard Ed. 8 API Documentation java.security.SecureRandom API
Java™ Cryptography Architecture Standard Algorithm Name Documentation for Java SE 7 SecureRandom Number Generation (RNG) Algorithms
Java™ Cryptography Architecture Standard Algorithm Name Documentation for Java SE 8 SecureRandom Number Generation (RNG) Algorithms