There is no change to the values returned by the system properties java.specification.version and java.vm.specification.version. They continue to report "1.8". If an application needs to identify the release, the system property java.version may be used.

Eras in the Japanese imperial calendar are tied to the reign of the emperor. On 1 May 2019, a new era will be introduced with the ascension of the new emperor. The specification of java.time.chrono.JapaneseEra was modified so that the singleton instances of JapaneseEra returned by values() (representing all the eras supported by the Java SE Platform) do not necessarily correspond to the static fields declared in JapaneseEra for convenience.

• Enhance the JapaneseEra class description:

  An era in the Japanese Imperial calendar system.

  This class defines the valid eras for the Japanese chronology. Japan introduced the Gregorian calendar starting with Meiji 6. Only Meiji and later eras are supported; dates before Meiji 6, January 1 are not supported.

  The Japanese government defines the official name and start date of each era. Eras are consecutive and their date ranges do not overlap, so the end date of one era is always the day before the start date of the next era.

  The Java SE Platform supports all eras defined by the Japanese government, beginning with the Meiji era. Each era is identified in the Platform by an integer value and a name. The of(int) and valueOf(String) methods may be used to obtain a singleton instance of JapaneseEra for each era. The values() method returns the singleton instances of all supported eras.

  For convenience, this class declares a number of public static final fields that refer to singleton instances returned by the values() method.

  API Note:

  The fields declared in this class may evolve over time, in line with the results of the values() method. However, there is not necessarily a 1:1 correspondence between the fields and the singleton instances.

  API Note:

  The Japanese government may announce a new era and define its start date but not its official name. In this scenario, the singleton instance that represents the new era may return a name that is not stable until the official name is defined. Developers should exercise caution when relying on the name returned by any singleton instance that does not correspond to a public static final field.

  Implementation Requirements:

  This class is immutable and thread-safe.

• Modify the of(int) method description:

  Obtains an instance of JapaneseEra from an int value.

  The SHOWA era that contains 1970-01-01 (ISO calendar system) has the value 1. Later era is numbered 2 (HEISEI). Earlier eras are numbered 0 (TAISHO), -1 (MEIJI), only Meiji and later eras are supported.

  • The value 1 is associated with the 'Showa' era, because it contains 1970-01-01 (ISO Calendar System).
  • The values -1 and 0 are associated with two earlier eras, Meiji and Taisho, respectively.
  • A value greater than 1 is associated with a later era, beginning with Heisei (2).

  Every instance of JapaneseEra that is returned from the values() method has an int value (available via Era.getValue() which is accepted by this method.

• Modify the definition of the HEISEI field descriptor:

  The singleton instance for the 'Heisei' era (1989-01-08 - current 2019-04-30) which has the value 2.

The enhancements associated with this change are 8215926.

In the Java SE Platform, support for the Unicode Standard is vested mainly in the java.lang.Character class. The specification of Character was modified to permit use of the "Currency Symbols" block (U+20A0 - U+20CF) from Unicode 10.0. The block had evolved materially since Unicode 6.2 (the version supported by the Final Release and Maintenance Release 1 of Java SE 8), to include currencies such as the Russian Ruble and Bitcoin.

In addition, the specification of Character was modified to permit use of the new Japanese Era code point, U+32FF, from the first version of the Unicode Standard after 6.2 that assigns the code point. An exception was made for the methods of Character that determine valid identifiers in the Java programming language; those methods were required to support Unicode 6.2 exactly, to maintain source compatibility of identifiers in Java programs.

• Modify the initial section of the Character class description:

  The Character class wraps a value of the primitive type char in an object. An object of type class Character contains a single field whose type is char.

  In addition, this class provides several a large number of static methods for determining a character's category (lowercase letter, digit, etc.) and for converting characters from uppercase to lowercase and vice versa. Character information is based on the

  Unicode Standard, version 6.2. Conformance

  The fields and methods and data of class Character are defined by in terms of character information from the information in Unicode Standard, specifically the UnicodeData file that is part of the Unicode Character Database maintained by the Unicode Consortium. This file specifies various properties including name and general category for every defined assigned Unicode code point or character range. The file and its description are is available from the Unicode Consortium at http://www.unicode.org.

  The Java SE 8 Platform uses character information from version 6.2 of the Unicode Standard, with two extensions. First, the Java SE 8 Platform allows an implementation of class Character to use the Japanese Era code point, U+32FF, from the first version of the Unicode Standard after 6.2 that assigns the code point. Second, in recognition of the fact that new currencies appear frequently, the Java SE 8 Platform allows an implementation of class Character to use the Currency Symbols block from version 10.0 of the Unicode Standard. Consequently, the behavior of fields and methods of class Character may vary across implementations of the Java SE 8 Platform when processing the aforementioned code points (outside of version 6.2), except for the following methods that define Java identifiers: isJavaIdentifierStart(int), isJavaIdentifierStart(char), isJavaIdentifierPart(int), and isJavaIdentifierPart(char). Code points in Java identifiers must be drawn from version 6.2 of the Unicode Standard.

• Add the following sentence to the isJavaIdentifierPart(char), isJavaIdentifierPart(int), isJavaIdentifierStart(char), isJavaIdentifierStart(int), isJavaLetter(char), and isJavaLetterOrDigit(char) method descriptions:

  These conditions are tested against the character information from version 6.2 of the Unicode Standard.

Additionally, minor corrections were made to the following method descriptions:

• isJavaLetter(char):

  A character may start a Java identifier if and only if one of the following conditions is true:

• isJavaLetterOrDigit(char):

  A character may be part of a Java identifier if and only if any the following conditions is true:

• isJavaIdentifierPart(char):

  A character may be part of a Java identifier if any of the following conditions are true:

• isJavaIdentifierPart(int):

  A character may be part of a Java identifier if any of the following conditions are true:

  • ...
  • isIdentifierIgnorable(codePoint) returns true for the character code point

The enhancement associated with this change is 8216396.

As industry-wide cryptographic standards evolve, the set of algorithms and protocols supported by the security APIs needs to change. The Java Security Standard Algorithm Names specification defines the set of String names referencing these standards (e.g. "SHA-256", "TLSv1.3"). The specification was modified to explicitly allow the addition of names for algorithms/protocols defined in later releases. The following text describes revisions to the beginning of the "Standard Names" section.

The JDK Java SE Security API requires and uses a set of standard names for algorithms, certificate and keystore types. This specification establishes the following names as standard names.

Note that an SE implementation may support additional algorithms that are not defined in this specification. As a best practice, if an algorithm is defined in a subsequent version of this specification and an implementation of an earlier specification supports that algorithm, the implementation should use the standard name of the algorithm that is defined in the subsequent specification. Each SE implementation should also document the algorithms that it supports or adds support for in subsequent update releases. The algorithms may be documented in release notes or in a separate document such as the JDK Security Providers document.

In some cases naming conventions are given for forming names that are not explicitly listed, to facilitate name consistency across provider implementations. Items in angle brackets (such as <digest> and <encryption>) are placeholders to be replaced by a specific message digest, encryption algorithm, or other name.

Note: Standard names are not case-sensitive.

The enhancements associated with this change are 8215320 and 8216071.