Hello, world
\n" + " \n" + "\n"; ``` _Using a "two-dimensional" block of text_ ``` String html = """Hello, world
"""; ``` ### SQL example _Using "one-dimensional" string literals_ ``` String query = "SELECT \"EMP_ID\", \"LAST_NAME\" FROM \"EMPLOYEE_TB\"\n" + "WHERE \"CITY\" = 'INDIANAPOLIS'\n" + "ORDER BY \"EMP_ID\", \"LAST_NAME\";\n"; ``` _Using a "two-dimensional" block of text_ ``` String query = """ SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB" WHERE "CITY" = 'INDIANAPOLIS' ORDER BY "EMP_ID", "LAST_NAME"; """; ``` ### Polyglot language example _Using "one-dimensional" string literals_ ``` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj = engine.eval("function hello() {\n" + " print('\"Hello, world\"');\n" + "}\n" + "\n" + "hello();\n"); ``` _Using a "two-dimensional" block of text_ ``` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj = engine.eval(""" function hello() { print('"Hello, world"'); } hello(); """); ``` Description ----------- > _This section is identical to the same section in this JEP's predecessor, [JEP 355](https://openjdk.java.net/jeps/355), except for the addition of the subsection on [new escape sequences](#New-escape-sequences)._ A _text block_ is a new kind of literal in the Java language. It may be used to denote a string anywhere that a _[string literal](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5)_ could appear, but offers greater expressiveness and less accidental complexity. A text block consists of zero or more content characters, enclosed by opening and closing delimiters. The _opening delimiter_ is a sequence of three double quote characters (`"""`) followed by zero or more white spaces followed by a line terminator. The _content_ begins at the first character after the line terminator of the opening delimiter. The _closing delimiter_ is a sequence of three double quote characters. The content ends at the last character before the first double quote of the closing delimiter. The content may include double quote characters directly, unlike the characters in a string literal. The use of `\"` in a text block is permitted, but not necessary or recommended. Fat delimiters (`"""`) were chosen so that `"` characters could appear unescaped, and also to visually distinguish a text block from a string literal. The content may include line terminators directly, unlike the characters in a string literal. The use of `\n` in a text block is permitted, but not necessary or recommended. For example, the text block: ``` """ line 1 line 2 line 3 """ ``` is equivalent to the string literal: ``` "line 1\nline 2\nline 3\n" ``` or a concatenation of string literals: ``` "line 1\n" + "line 2\n" + "line 3\n" ``` If a line terminator is not required at the end of the string, then the closing delimiter can be placed on the last line of content. For example, the text block: ``` """ line 1 line 2 line 3""" ``` is equivalent to the string literal: ``` "line 1\nline 2\nline 3" ``` A text block can denote the empty string, although this is not recommended because it needs two lines of source code: ``` String empty = """ """; ``` Here are some examples of ill-formed text blocks: ``` String a = """"""; // no line terminator after opening delimiter String b = """ """; // no line terminator after opening delimiter String c = """ "; // no closing delimiter (text block continues to EOF) String d = """ abc \ def """; // unescaped backslash (see below for escape processing) ``` ### Compile-time processing A text block is a [constant expression](https://docs.oracle.com/javase/specs/jls/se12/html/jls-15.html#jls-15.28) of type `String`, just like a string literal. However, unlike a string literal, the content of a text block is processed by the Java compiler in three distinct steps: 1. Line terminators in the content are translated to LF (`\u000A`). The purpose of this translation is to follow the principle of least surprise when moving Java source code across platforms. 2. Incidental white space surrounding the content, introduced to match the indentation of Java source code, is removed. 3. Escape sequences in the content are interpreted. Performing interpretation as the final step means developers can write escape sequences such as `\n` without them being modified or deleted by earlier steps. The processed content is recorded in the `class` file as a `CONSTANT_String_info` entry in the constant pool, just like the characters of a string literal. The `class` file does not record whether a `CONSTANT_String_info` entry was derived from a text block or a string literal. At run time, a text block is evaluated to an instance of `String`, just like a string literal. Instances of `String` that are derived from text blocks are indistinguishable from instances derived from string literals. Two text blocks with the same processed content will refer to the same instance of `String` due to [interning](https://docs.oracle.com/javase/specs/jvms/se12/html/jvms-5.html#jvms-5.1-300), just like for [string literals](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5-410). The following sections discuss compile-time processing in more detail. #### 1. Line terminators Line terminators in the content are _normalized_ from CR (`\u000D`) and CRLF (`\u000D\u000A`) to LF (`\u000A`) by the Java compiler. This ensures that the string derived from the content is equivalent across platforms, even if the source code has been translated to a platform encoding (see `javac -encoding`). For example, if Java source code that was created on a Unix platform (where the line terminator is LF) is edited on a Windows platform (where the line terminator is CRLF), then without normalization, the content would become one character longer for each line. Any algorithm that relied on LF being the line terminator might fail, and any test that needed to verify string equality with `String::equals` would fail. The escape sequences `\n` (LF), `\f` (FF), and `\r` (CR) are _not_ interpreted during normalization; escape processing happens later. #### 2. Incidental white space The text blocks [shown above](#Motivation) were easier to read than their concatenated string literal counterparts, but the obvious interpretation for the content of a text block would include the spaces added to indent the embedded string so that it lines up neatly with the opening delimiter. Here is the HTML example using dots to visualize the spaces that the developer added for indentation: ``` String html = """ .............. .............. ..............Hello, world
.............. .............. .............."""; ``` Since the opening delimiter is generally positioned to appear on the same line as the statement or expression which consumes the text block, there is no real significance to the fact that 14 visualized spaces start each line. Including those spaces in the content would mean the text block denotes a string different from the one denoted by the concatenated string literals. This would hurt migration, and be a recurring source of surprise: it is overwhelmingly likely that the developer does _not_ want those spaces in the string. Also, the closing delimiter is generally positioned to align with the content, which further suggests that the 14 visualized spaces are insignificant. Spaces may also appear at the end of each line, especially when a text block is populated by copy-pasting snippets from other files (which may themselves have been formed by copy-pasting from yet more files). Here is the HTML example reimagined with some trailing white space, again using dots to visualize spaces: ``` String html = """ ................. .............. ..............Hello, world
.... .............. . ................. .............."""; ``` Trailing white space is most often unintentional, idiosyncratic, and insignificant. It is overwhelmingly likely that the developer does not care about it. Trailing white space characters are similar to line terminators, in that both are invisible artifacts of the source code editing environment. With no visual guide to the presence of trailing white space characters, including them in the content would be a recurring source of surprise, as it would affect the length, hash code, etc, of the string. Accordingly, an appropriate interpretation for the content of a text block is to differentiate _incidental white space_ at the start and end of each line, from _essential white space_. The Java compiler processes the content by removing incidental white space to yield what the developer intended. `String::indent` can then be used to further manipulate indentation if desired. Using `|` to visualize margins: ``` || | | |Hello, world
| | | || ``` The _re-indentation algorithm_ takes the content of a text block whose line terminators have been normalized to LF. It removes the same amount of white space from each line of content until at least one of the lines has a non-white space character in the leftmost position. The position of the opening `"""` characters has no effect on the algorithm, but the position of the closing `"""` characters does have an effect if placed on its own line. The algorithm is as follows: 1. Split the content of the text block at every LF, producing a list of _individual lines_. Note that any line in the content which was just an LF will become an empty line in the list of individual lines. 2. Add all _non-blank_ lines from the list of individual lines into a set of _determining lines_. (Blank lines -- lines that are empty or are composed wholly of white space -- have no visible influence on the indentation. Excluding blank lines from the set of determining lines avoids throwing off step 4 of the algorithm.) 3. If the last line in the list of individual lines (i.e., the line with the closing delimiter) is _blank_, then add it to the set of determining lines. (The indentation of the closing delimiter should influence the indentation of the content as a whole -- a [_significant trailing line_](#Significant-trailing-line-policy) policy.) 4. Compute the _common white space prefix_ of the set of determining lines, by counting the number of leading white space characters on each line and taking the minimum count. 5. Remove the common white space prefix from each _non-blank_ line in the list of individual lines. 6. Remove all trailing white space from all lines in the modified list of individual lines from step 5. This step collapses wholly-white-space lines in the modified list so that they are empty, but does not discard them. 7. Construct the result string by joining all the lines in the modified list of individual lines from step 6, using LF as the separator between lines. If the final line in the list from step 6 is empty, then the joining LF from the previous line will be the last character in the result string. The escape sequences `\b` (backspace), `\t` (tab) and `\s` (space) are _not_ interpreted by the algorithm; escape processing happens later. Similarly, the `\Hello, world
"""; ``` Including the trailing blank line with the closing delimiter, the common white space prefix is zero, so zero white space is removed from the start of each line. The algorithm thus produces: (using `|` to visualize the left margin) ``` | | |Hello, world
| | ``` Alternatively, suppose the closing delimiter is not moved all the way to the left, but rather under the `t` of `html` so it is eight spaces deeper than the variable declaration: ``` String html = """Hello, world
"""; ``` The spaces visualized with dots are considered to be incidental: ``` String html = """ ........ ........ ........Hello, world
........ ........ ........"""; ``` Including the trailing blank line with the closing delimiter, the common white space prefix is eight, so eight white spaces are removed from the start of each line. The algorithm thus preserves the essential indentation of the content relative to the closing delimiter: ``` | | |Hello, world
| | ``` Finally, suppose the closing delimiter is moved slightly to the _right_ of the content: ``` String html = """Hello, world
"""; ``` The spaces visualized with dots are considered to be incidental: ``` String html = """ .............. .............. ..............Hello, world
.............. .............. .............. """; ``` The common white space prefix is 14, so 14 white spaces are removed from the start of each line. The trailing blank line is stripped to leave an empty line, which being the last line is then discarded. In other words, moving the closing delimiter to the right of the content has no effect, and the algorithm again preserves the essential indentation of the content: ``` | | |Hello, world
| | ``` #### 3. Escape sequences After the content is re-indented, any _escape sequences_ in the content are interpreted. Text blocks support all of the escape sequences supported in string literals, including `\n`, `\t`, `\'`, `\"`, and `\\`. See [section 3.10.6](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.6) of the _The Java Language Specification_ for the full list. Developers will have access to escape processing via `String::translateEscapes`, a new instance method. Interpreting escapes as the final step allows developers to use `\n`, `\f`, and `\r` for vertical formatting of a string without it affecting the translation of line terminators in step 1, and to use `\b` and `\t` for horizontal formatting of a string without it affecting the removal of incidental white space in step 2. For example, consider this text block that contains the `\r` escape sequence (CR): ``` String html = """ \r \rHello, world
\r \r \r """; ``` The CR escapes are not processed until after the line terminators have been normalized to LF. Using Unicode escapes to visualize LF (`\u000A`) and CR (`\u000D`), the result is: ``` |\u000D\u000A | \u000D\u000A |Hello, world
\u000D\u000A | \u000D\u000A |\u000D\u000A ``` Note that it is legal to use `"` and `""` freely inside a text block, except immediately before the closing delimiter. For example, the following text blocks are legal: ``` String story = """ "When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean - neither more nor less." "The question is," said Alice, "whether you can make words mean so many different things." "The question is," said Humpty Dumpty, "which is to be master - that's all." """; // Note the newline before the closing delimiter String code = """ String empty = ""; """; ``` However, a sequence of three `"` characters requires at least one `"` to be escaped, in order to avoid mimicking the closing delimiter. (A sequence of n `"` characters requires at least `Math.floorDiv(n,3)` of them to be escaped.) The use of `"` immediately before the closing delimiter also requires escaping. For example: ``` String code = """ String text = \""" A text block inside a text block \"""; """; String tutorial1 = """ A common character in Java programs is \""""; String tutorial2 = """ The empty string literal is formed from " characters as follows: \"\""""; System.out.println(""" 1 " 2 "" 3 ""\" 4 ""\"" 5 ""\""" 6 ""\"""\" 7 ""\"""\"" 8 ""\"""\""" 9 ""\"""\"""\" 10 ""\"""\"""\"" 11 ""\"""\"""\""" 12 ""\"""\"""\"""\" """); ``` ### New escape sequences To allow finer control of the processing of newlines and white space, we introduce two new escape sequences. First, the `\foo with javadoc tag {@code foo} in java.base
JDK-8214546: Start of release updates for JDK 14
JDK-8236779: static field in implementation class erroneously leaking in memory access javadoc
JDK-8225320: Umbrella: JDK 14 terminal deprecations
JDK-8226831: Use Objects.equals() when appropriate
core-libs/java.io:
JDK-8230681: Add @since tag to java.io.Serial
JDK-8228392: Backout incorrect change done by JDK-8067801
JDK-8229022: BufferedReader performance can be improved by using StringBuilder
JDK-8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument
JDK-8067801: Enforce null check for underlying I/O streams
JDK-8179320: File.getUsableSpace() returns a negative number on very large file system
JDK-8228204: Fix for JDK-8067801 breaks java/io/NegativeInitSize.java
JDK-8232168: Fix non wide char canonicalization on Windows
JDK-8229899: java.io.File.isInvalid() is racy
JDK-8078891: java.io.SequenceInputStream.close is not atomic and not idempotent
JDK-8229333: java/io/File/SetLastModified.java timed out
JDK-8131664: Javadoc for PrintStream is now incorrect
JDK-8073213: javadoc of PushbackInputStream methods should specify NullPointerExceptions
JDK-8235668: LineNumberReader#getLineNumber() returns wrong line number (one fewer) in Lucene test
JDK-8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF
JDK-8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause
JDK-8228338: tools/pack200/TimeStamp.java fails with NullPointerException
JDK-8234781: Update description of InvalidClassException to include more conditions
core-libs/java.io:serialization:
JDK-8237651: Clarify initialization of jdk.serialFilter
JDK-8199424: consider removing ObjectInputStream and ObjectOutputStream native methods
JDK-8234782: Discuss evolution of records in serialization spec
JDK-8237019: Serialization Specification changes for Records
JDK-8235531: Update record serialization migration tests to not use hard coded source versions
JDK-8235514: Update record serialization tests to not use hard coded source versions
JDK-8231427: Warning cleanup in tests of java.io.Serializable
core-libs/java.lang:
JDK-8229485: Add decrementExact(), incrementExact(), and negateExact() to java.lang.StrictMath
JDK-8232135: Add diagnostic output to test java/util/ProcessBuilder/Basic.java
JDK-8227587: Add internal privileged System.loadLibrary
JDK-8221623: Add StackWalker micro benchmarks to jdk repo
JDK-8202385: Annotation to mark serial-related fields and methods
JDK-8234381: API docs should mention special handling of enums in serialization
JDK-8229997: Apply java.io.Serial annotations in java.base
JDK-8229407: Avoid ConcurrentHashMap resizes during bootstrap
JDK-8226809: Circular reference in printed stack trace is not correctly indented & ambiguous
JDK-8227202: clarify Class.isEnum() doc
JDK-8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call
JDK-8205132: Degrade Thread.countStackFrames() to throw UOE
JDK-8231602: Deprecate Thread.suspend/resume for removal
JDK-8226242: Diagnostic output for posix_spawn failure
JDK-8233658: Escape + in the expression describing Runtime.Version string
JDK-8233116: Escape Sequences For Line Continuation and White Space (Preview)
JDK-8231717: Improve performance of charset decoding when charset is always compactable
JDK-8230074: Improve specification for {Math, StrictMath}.negateExact
JDK-8234783: Improve wording of spec of Record.equals
JDK-8232624: Java cannot start: NewStringPlatform missing
JDK-8229337: java.lang.Math class doc should be adjusted regarding -Exact methods
JDK-8236695: java.lang.Record should be declared with an explicit constructor
JDK-8233650: Javadoc for Math.floorMod(int, int) gives wrong example
JDK-8230104: JNU_IsInstanceOfByName needs const parameter
JDK-8233940: Preview API tests for String methods should use ${jdk.version} as -source arg
JDK-8230723: Remove default constructors from java.lang and java.io
JDK-8232724: Remove indirection with calling JNU_NewStringPlatform
JDK-8226286: Remove unused method java.lang.Integer::formatUnsignedInt and cleanup Integer/Long classes
JDK-8231355: Remove unused utility methods in libjava
JDK-8227113: Specification for java.lang.Record
JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767
JDK-8221307: String.substring() OOB exception on start index reports improper information
JDK-8233751: StringBuilder / StringBuffer capacity() doc is misleading
JDK-8229283: StringLatin1 should consistently use CharacterDataLatin1.instance when applicable
JDK-8232617: Update the outdated code comments in java.lang.System class
JDK-8229831: Upgrade Character.isUnicodeIdentifierStart/Part() methods to the latest standard
JDK-8230373: Use java.io.Serial in generated exception types
core-libs/java.lang.invoke:
JDK-8230768: Arrays of SoftReferences in MethodTypeForm should not be @Stable
JDK-8234401: ConstantCallSite may stuck in non-frozen state
JDK-8228671: Fastdebug VM throws InternalError when publicLookup.in(T) is used to resolve a member
JDK-8230302: GenerateJLIClassesPlugin can generate invalid DirectMethodHandle methods
JDK-8232806: Introduce a system property to disable eager lambda initialization
JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access
JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works
JDK-8173975: Lookup::in should not allow target class be primitive or array class
JDK-8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag
JDK-8233956: MethodHandles.dropArguments javadoc lists parameters in wrong order
JDK-8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types
JDK-8229785: MethodType::fromMethodDescriptorString should require security permission if loader is null
JDK-8230662: Remove dead code from MethodTypeForm
JDK-8236945: typo "the the" in Lookup::in javadoc
JDK-8209078: Unable to call default method from interface in another module from named module
core-libs/java.lang.module:
JDK-8233922: Service binding augments module graph with observable incubator modules
core-libs/java.lang:class_loading:
JDK-8233091: Backout JDK-8212117: Class.forName loads a class but not linked if class is not initialized
JDK-8212117: Class.forName may return a reference to a loaded but not linked Class
JDK-8235361: JAR Class-Path no longer accepts relative URLs encoding absolute Windows paths (e.g "/C:/...")
JDK-8233272: The Class.forName specification should be updated to match the long-standing implementation with respect to class linking
JDK-8139820: URLClassPath.FileLoader constructor redundantly checks protocol
core-libs/java.lang:reflect:
JDK-8207814: (proxy) upgrade the proxy class generator to support new class file version
JDK-8236877: Add "record" to descriptions in java.lang.{annotation, reflect}
JDK-8235550: Clarify record reflective support specification
JDK-8235369: Class.toGenericString need to be updated for records
JDK-8234917: Explicitly discuss java.lang.Enum in Class.isEnum spec
JDK-8225053: Preview APIs support for records
JDK-8219774: Reexamine the initialization of LangReflectAccess shared secret at AccessibleObject::in Instrumentation.java JDK-8225679: reference to http://java.sun.com/products/JavaManagement/download.html JDK-8225682: Reference to JNI spec on java.sun.com JDK-8228834: Regression caused by JDK-8214542 not installing complete checkpoint data to candidates JDK-8225429: Regression in disassembly quality JDK-8221481: Reimplement the Legacy Socket API JDK-8223766: Remains of ancient code in AWT initialization JDK-8224814: Remove dead JNIHandleBlock freelist code JDK-8224497: Remove FIXME in metaspaceClosure.cpp JDK-8225171: Remove leftovers in shenandoahBarrierSetC1.cpp JDK-8228399: Remove mistaken open.iml JDK-8205131: remove Runtime trace methods JDK-8225564: Remove wrong assert in clean_catch_blocks JDK-8224790: Remove Xusage.txt file JDK-8225321: Repeated use of {@systemProperty} in a file causes duplicate ids JDK-8225426: Replace plain with system-default in Socket and ServerSocket JDK-8221709: replace use of style blockListLast JDK-8224865: Replace wildcard address with loopback or local host in tests - part 13 JDK-8225512: Replace wildcard address with loopback or local host in tests - part 15 JDK-8224908: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits /modules element from file path JDK-8225357: Rewire ShenandoahHeap::maybe_update_with_forwarded for contending fixups JDK-8224952: RI deviates from JVMS - non-zero minor_version for class files throws UnsupportedClassVersionError. JDK-8225118: Robot.createScreenCapture() returns black image on HiDPI linux with gtk3 JDK-8193255: Root Certificates should be stored in text format and assembled at build time JDK-8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. JDK-8224692: runtime/appcds tests crash in "HotSpotJVMCI::compute_offset" when running in Graal as JIT mode JDK-8188872: runtime/ErrorHandling/TimeoutInErrorHandlingTest.java fails intermittently JDK-8228618: s390: c1/c2 fail to add a metadata relocation in the static call stub. JDK-8227437: S4U2proxy cannot continue because server's TGT cannot be found JDK-8223814: SA: jhsdb common help needs to be more detailed JDK-8225702: Safepoint counter can't be used for safepoint detection JDK-8224531: SEGV while collecting Klass statistics JDK-8225014: Separate ShenandoahRootScanner method for object_iterate JDK-8227541: Serial spec should be updated to reflect API generification JDK-8216988: ServerSocket.implAccept should include warnings about Socket type/state JDK-8220449: serviceability/dcmd/compiler/CodelistTest.java failure JDK-8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout JDK-8225348: serviceability/dcmd/vm/EventsTest.java failed JDK-8211018: Session Resumption without Server-Side State JDK-8227551: Session Resumption without Server-Side State off by default JDK-8226651: Setting the mgfHash in CK_RSA_PKCS_PSS_PARAMS has no effect JDK-8221632: Several corrections to java FlightRecorderOptions section JDK-8224496: Shenandoah compilation fails with assert(is_CountedLoopEnd()) failed: invalid node class JDK-8225046: Shenandoah metrics logs refactoring JDK-8225048: Shenandoah x86_32 support JDK-8224978: Shenandoah: Allows root verifier to verify some roots outside safepoints with proper locks JDK-8225341: Shenandoah: CM::update_thread_roots() needs to handle derived pointers JDK-8224584: Shenandoah: Eliminate forwarding pointer word JDK-8225572: Shenandoah: Move JNIHandles root out of serial roots JDK-8224875: Shenandoah: ParallelCleaning code unloading should take lock to protect shared code roots array JDK-8224932: Shenandoah: Rename ShenandoahHeapLock, make it general purpose lock JDK-8225514: Shenandoah: ShenandoahCodeRoots should inherit from AllStatic JDK-8225229: Shenandoah: trim down default number of GC threads JDK-8225342: Shenandoah: use COMPILER2_OR_JVMCI macro consistently JDK-8224970: ShenandoahRootScanner::roots_do assert is too strong JDK-8225180: SignedObject with invalid Key not throwing the InvalidKeyException in Windows JDK-8228403: SignTwice.java failed with java.io.FileNotFoundException: File name too long JDK-8228341: SignTwice.java fails intermittently on Windows JDK-8077317: Silent uninstall is not documented for Java 7 JDK-8225214: Socket.getOption(SocketOption) not returning the expected type for the StandardSocketOptions.SO_LINGER JDK-8224081: SOCKS v4 tests require IPv4 JDK-8224795: some runtime/SelectionResolution tests are timing out JDK-8226654: Some swing gtk regression tests fail with "java.lang.InternalError: Unable to load native GTK libraries" JDK-8223271: SplashScreen is still shown if defaulting to headless on MacOS JDK-8227011: Starting a JFR recording in response to JVMTI VMInit and / or Java agent premain corrupts memory JDK-8203444: String::formatted (Preview) JDK-8223775: String::stripIndent (Preview) JDK-8223780: String::translateEscapes (Preview) JDK-8225448: String::translateEscapes javadoc has accessibility issues JDK-8225225: stringStream internal buffer should always be zero terminated JDK-8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use JDK-8227422: sun/net/www/protocol/file/DirPermissionDenied.java failed on Windows 2016 because DirPermissionDenied directory has no read permission JDK-8227059: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timed out JDK-8225257: sun/security/tools/keytool/PSS.java timed out JDK-8225671: Support HTML 5 character references in javadoc JDK-8215032: Support Kerberos cross-realm referrals (RFC 6806) JDK-8222083: Support of "64-bit IEEE floating point" encoding for the AU file format JDK-8171279: Support X25519 and X448 in TLS JDK-8229018: Switching to an infinite socket timeout on Windows leads to high CPU load JDK-8226302: Test failures on IBM platforms (power and s/390) after JDK-8223837 JDK-8225386: test for JDK-8216261 fails in Windows JDK-8224645: Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException JDK-8225315: test java/util/ArrayDeque/WhiteBox.java isn't part of the jdk_collections test group JDK-8226869: Test java/util/Locale/LocaleProvidersRun.java should enable assertions JDK-8224151: Test vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java might hang with release binaries JDK-8224778: test/jdk/demo/jfc/J2Ddemo/J2DdemoTest.java cannot find J2Ddemo.jar JDK-8224830: test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java fails on linux-x64 JDK-8226628: The copyright footer should be enclosed in