clair077

Three more Java Enhancement Proposals were proposed for targeting JDK 11 today. The three JEPs are JEP 181 ["http://openjdk.java.net/jeps/181"], JEP 315 ["JEP 315: Improve Aarch64 Intrinsics"], and JEP 333 ["JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)"]. The targeting of these three JEPs for JDK 11 was announced today on the OpenJDK jdk-dev mailing list in the respective posts " JEP proposed to target JDK 11: 181: Nest-Based Access Control ", " JEP proposed to target JDK 11: 315: Improve Aarch64 Intrinsics ", and " JEP proposed to target JDK 11: 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) ". Each JEP proposal is open for roughly one week and, if there are no objections, will be targeted officially to JDK 11 next week. The purpose of JEP 181 is to "introduce nests " and the JEP's "Summary" states that "nests" are significant because they ...

In the third chapter of his 2014 book " Java SE 8 for the Really Impatient: Programming with Lambdas ," Cay Horstmann writes, "The point of all lambdas is deferred execution ." He adds, "After all, if you wanted to execute some code right now, you'd do that, without wrapping it inside a lambda." Horstmann then lists several examples of the "many reasons for executing code later" and his last listed reason is "Running the code only when necessary." In this post, I look at some examples of this from the JDK that use Supplier to do exactly that: to execute a "code block" represented as a lambda expression "only when necessary." When JDK 8 introduced lambda expressions , it also introduced several standard functional interfaces in its java.util.function package. That package's Javadoc documentation states, " Functional interfaces provide target types for lambda expressions and method references....

Although it was never a central goal of JEP 330 ["Launch Single-File Source-Code Programs"] to add support for the Unix-style shebang ( #! ), issues surrounding the potential ability of JEP 330 "single file source programs" to support a Unix-style shebang have generated significant discussion on the OpenJDK jdk-dev mailing list . This "vigorous discussion" has led to Mark Reinhold adding a week to the review period (now ends on May 31) for JEP 330 to allow for further discussion regarding targeting JEP 330 for JDK 11 . Although there are still some disagreements about whether shebang support should be added at all , it does seem that consensus is shifting to a proposal to explicitly differentiate between regular platform-independent Java source code files (those that end with extension .java ) and the new JEP 330 "executable" platform-specific "single-file source-code programs". The explicit distinction is noteworthy because it ...

JDK-8203630 ["Add instance method equivalents for String::format"] postulates that "the argument for implementing String::format as static appears to be that the format methods could be imported statically and thus conduct themselves comparably to C 's sprintf ." On a StackOverflow.com thread on the subject , Brandon Yarbrough writes, "by making the method static you can use format in a way that's very familiar and clean-looking to C programmers used to printf() ." Yarbrough provides a code example and then concludes, "By using static imports, printfs look almost exactly like they do in C. Awesome!" When I read in JDK-8203630 about this, I wondered to myself why I had not statically imported String.format when I've used it because it seems obvious to me now to do that. In this post, I look briefly at some personal theories I have considered to explain why I (and many others apparently) have not thought to statically import Stri...

This past week, two Mark Reinhold messages ( here and here ) on the OpenJDK jdk-dev mailing list proposed two new JEPs for inclusion with JDK 11 : JEP 329 ["ChaCha20 and Poly1305 Cryptographic Algorithms"] and JEP 330 ["Launch Single-File Source-Code Programs"]. I am excited about JEP 330 , but that enthusiasm led me to blog on it when it was but a mere "draft" JEP (not even assigned to the 330 number at that point). The focus of the remainder of this post will therefore be on JEP 329 . The intent of JEP 329 is succinctly described in the JEP's "Summary" section: "Implement the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539 ." That same "Summary" section also states, "ChaCha20 is a relatively new stream cipher that can replace the older, insecure RC4 stream cipher ." The RC4 (Rivest Cipher 4) stream cipher has already been disabled in major web browsers (early 2016) due to security ri...

My previous post focused on the Files.isSameContent() method that is likely to be added to JDK 11 . JDK-8201276 ["(fs) Add methods to Files for reading/writing a string from/to a file"] mentions this new method and also highlights the methods that are the subjects of this post: readString(Path) readString(Path, Charset) writeString(Path, CharSequence, OpenOption...) writeString(Path, CharSequence, Charset, OpenOption...) Joe Wang recently posted the message "RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file" on the core-libs-dev mailing list . In this message, Wang provided links to the related bug ( JDK-8201276 ), to the proposed specification (API) differences , and to the proposed code changes . This is another case where a proposed change leads to some interesting discussion. The thread started with this message includes discussion regarding whether or not to include operating-system specific line separators Fi...

It has been proposed that a method named isSameContents() be added to the Files class in JDK 11 via JDK-8202285 ["(fs) Add a method to Files for comparing file contents"]. Proposed by Joe Wang , this new method is "intended to be an extension to the existing isSameFile method since it stopped short of comparing the content to answer the query for whether two files are equal." JDK-8201276 also references this method and describes it as "a utility method that compares two files." Regarding the usage of this new method, JDK-8202285 's Description states: Proposing a new Files method isSameContent . Files currently has a method called isSameFile that answers the query on whether or not two files are the same file. Since two files containing the same contents may also be viewed as the same, it is desirable to add a method that further compares the contents, that would make the "is same file" query complete. The OpenJDK core-libs-dev mai...

Jim Laskey's recent message " RFR: CSR - JDK-8203428 Predicate::not " on the OpenJDK core-libs-dev mailing list calls out JDK Bug JDK-8203428 ["Predicate::not"]. The "Summary" of JDK-8203428 states, "Introduce a new static method Predicate::not which will allow developers to negate predicate lambdas trivially." It is currently assigned to JDK 11 . The "Problem" section of JDK-8203428 provides a succinct description of the issue that Predicate::not addresses: The requirement for predicate negation occurs frequently since predicates are defined antipodal to a positive selection; isNull, isEmpty, isBlank. Presently there is no easy way to negate a predicate lambda without first wrapping in a Predicate Object. There is a highly illustrative example of how this would work in the JDK-8203428 write-up. The "Problem" section of JDK-8203428 provides code that demonstrates how "predicate negation" would be perf...

Three new JEPs were targeted for JDK 11 a week ago today (7 May 2014). In three separate messages on the jdk-dev mailing list , Mark Reinhold made the following announcements: JEP proposed to target JDK 11: 324: Key Agreement with Curve25519 and Curve448 JEP proposed to target JDK 11: 327: Unicode 10 JEP proposed to target JDK 11: 328: Flight Recorder JEP 324: Key Agreement with Curve25519 and Curve448 The "Summary" section of JEP 324 ("Key Agreement with Curve25519 and Curve448") states, "Implement key agreement using Curve25519 and Curve448 as described in RFC 7748 ." The Curve25519 entry on Wikipedia has an opening paragraph that makes it clear why this particular elliptic curve is well-suited as an addition to the JDK. It states that " Curve25519 is an elliptic curve offering 128 bits of security" that is "designed for use with the elliptic curve Diffie–Hellman (ECDH) key agreement scheme and is one of the fastest ECC curves a...

The JDK may be getting another standard (predefined) annotation with JDK 11 : @Serial . JDK-8202385 ["Annotation to mark serial-related fields and methods"] aims to add "some kind of 'SerialRelated' annotation to facilitate automated checking of the declarations of serial fields and methods." The idea is to better indicate to a developer when a serialization-related field or method is misspelled similar to the way that "the java.lang.Override annotation type is used to signal the compiler should verify the method is in fact overridden." Joe Darcy recently requested review of the " webrev " (proposed code addition). This provides a peek at what the new @Serial might look like. The current proposal is for this annotation definition to reside in the java.io package , to be targeted at specific methods or fields , and to have SOURCE retention . The Javadoc comments for the proposed definition of @Serial currently provide significa...

It appears likely that Java's String class will be gaining some new methods with JDK 11 , expected to be released in September 2018. BUG # BUG TITLE NEW String METHOD DESCRIPTION JDK-8200425 String::lines lines() "String instance method that uses a specialized Spliterator to lazily provide lines from the source string." JDK-8200378 String::strip, String::stripLeading, String::stripTrailing strip() "Unicode-aware" evolution of trim() stripLeading() "removal of Unicode white space from the beginning" stripTrailing() "removal of Unicode white space from the ... end" JDK-8200437 String::isBlank isBlank() "instance method that returns true if the string is empty or contains only white space" Evidence of the progress that has been made related to these methods can be found in messages requesting " compatibility and specification reviews " (CSR) on the core-libs-dev mailing list : Please review...