The first release candidates of Java 8 started showing up in early February. The first, b128, on February 4, and a second announced on the OpenJDK mailing list a week later.
Java 8 RC2 fixes a serious flaw in its new Comparator API, where its new thenComparing() had an unnecessary type restriction. From the bug report:
The following method of java.util.Comparator requires that type U extend java.lang.Comparable.<U extends Comparable<? super U>> Comparator<T> thenComparing( Function<? super T, ? extends U> keyExtractor, Comparator<? super U> keyComparator);But this restriction is unnecessary because keyComparator is used to compare extracted key objects.
Java 8 RC2 also fixes a read permission issue on Mac OS X. Java 8 Release Candidates can be downloaded from https://jdk8.java.net/download.html.
According to the bug tracker for JDK 8, the release will coincide with St. Patrick's Day on March 17th. At the time of this writing, there are three unresolved issues, all related to documentation.
In other Java 8-related news, Drew Stephens recently published numbers showing that Java 8's atomic number implementations are quite a bit faster. Also, Mark Reinhold proposed that Stripped Implementations be dropped from Java 8, citing legal issues as the reason.
New Atomic Number Implementations
In addition to Java 8's Lambdas (335) and new Date and Time API (JSR 310), it contains atomic number implementations that are very important to certain classes of multithreaded applications. Drew Stephens, Principle at Palamino Labs, recently wrote about the addition of LongAdder and DoubleAdder.
Less flashy, but very important to certain classes of multithreaded applications, are the addition of LongAdder and DoubleAdder, atomic Number implementations that provide superior performance to AtomicInteger and AtomicLong when under contention from multiple threads.
Some simple benchmarking illustrates the performance difference between the two–for the following benchmarks we used an m3.2xlarge EC2 instance, which provides access to all 8 cores of an Intel Xeon E5-2670.
With a single thread, the new LongAdder is one third slower, but when threads are in contention to increment the field, LongAdder shows its value. Note that the only thing each thread is doing is attempting to increment the counter–this is a synthetic benchmark of the most extreme kind. The contention here is higher than you're likely to see in most real-world apps, but sometimes you do need this sort of shared counter, and LongAdder will be a big help.
Drew goes on to show that AtomicLong is a bit quicker with single threads. However, it's four times slower with two threads and almost five times when the number of threads matches the number of cores. He also notes that "LongAdder's performance is constant until the number of threads exceeds the CPU's number of physical cores".
Stripped Implementations Dropped
Stripped implementations is a proposed feature for Java 8 that allows customized implementations of Java SE to be packaged with applications that run on it. Elements that don't depend on on the code that application uses can be removed. This type of implementation is likely useful for those wanting to embed Java in devices (e.g. household appliances).
Mark Reinhold recently proposed that Stripped Implementations be dropped from Java SE 8. He cited legal issues as the cause.
In order to preserve compatibility and guard against fragmentation, the Stripped Implementations feature of Java SE 8 requires some nontrivial changes to the TCK license.
I've been working with Oracle's legal department on these revisions for some time now. We have an initial draft but at this point, unfortunately, I don't think there is sufficient time for members of this Expert Group, members of the JCP Executive Committee, and other interested parties to review and comment on these changes.
I therefore propose to drop the Stripped Implementations feature from Java SE 8. This will only require changes to the Specification and to the TCK rules -- no change to the RI, or to actual TCK tests, is needed.
Reinhold also wrote that he believes Stripped Implementations is important to the future of the Java platform and it might be added in a release prior to Java SE 9.
Java 8's release is right around the corner. Easier dates, closures, better concurrency and a new JavaScript engine are just a month away! Will you be upgrading? If not, is there something technical that's stopping you?
