Most of us who develop with Java are generally enthusiastic for the features and improvements that come with JDK 8. However, there have been several recent posts that have pointed out some features that can be misused and abused and might lead to some additional issues in the future. These features, which remind me of the introduction of autoboxing in J2SE 5, have their useful situations, but can also lead to issues when not correctly understood and applied. In this post, I use references to other peoples’ posts written about these dubious features. Note that this post is not about the “normal” known issues that are associated with any release.
Lambda expressions seem to be the biggest new feature of JDK 8, but Tal Weiss has written a post called The Dark Side Of Lambda Expressions in Java 8. In that post, Weiss writes about a “dark side” to lambda expressions and the Nashorn JavaScript engine (which he argues is the second biggest feature of JDK 8). He talks about the “distance between your code and the runtime” and points out that “we’re paying the price for shorter, more concise code with more complex debugging, and longer synthetic call stacks.”
In Love and hate for Java 8, Andrew C. Oliver and Michael Brush provide a nice introduction to some of the main new features of JDK 8. They are argue that default methods on interfaces “allow a form of multiple inheritance” and will “probably [be] the detail that will concern most people in Java 8.” He concludes the article with the assessment, “The feature that is going to be dangerous is functional interfaces. If they are not used properly, they could cause a lot of headaches.”
Peter Verhas has written a detailed analysis of the potential issues with default methods on interfaces in the posts Java 8 default methods: what can and can not do? and How not to use Java 8 default methods. In one post, he states, “Adding a default method to an interface may render some class unusable.” In the other post, he adds, “The default method is a technological mistake” and references the fact that default methods were added to Java interfaces to support backward compatibility of existing implementations with methods that need to be added to interfaces to support new JDK 8 features.
Lukas Eder‘s The Dark Side of Java 8 post expresses different concerns about default methods: the inability to make a default method final or synchronized and introduction of the “default” keyword. Another interesting “caveat” pointed out in this post is the effect lambda expressions have on overloading.
Another Tal Weiss post, New Parallelism APIs in Java 8: Behind The Glitz and Glamour, looks at some issues Weiss observed when measuring performance of the “new Java 8 parallel operation APIs” under load. Weiss observes, “adding threads in what already is a multi-threaded environment doesn’t help you” and reminds us, “While these are very strong and easy-to-use APIs, they’re not a silver bullet. We still need to apply judgment as to when to employ them.”
Lukas Krecan warns Think twice before using Java 8 parallel streams and writes, “The problem is that all parallel streams use common fork-join thread pool and if you submit a long-running task, you effectively block all threads in the pool.” To deal with this, Krecan advises either “[ensuring] that all tasks submitted to the common fork-join pool will not get stuck and will finish in a reasonable time” or “not use parallel streams and wait until Oracle allows us to specify the thread pool to be used for parallel streams.”
Edwin Dalorzo‘s post Why There’s Interface Pollution in Java 8 looks at how type erasure, checked exceptions, and lack of value types (JEP 169) led to design decisions in JDK 8 that have “polluted” Java interfaces. The post mixes quotes from Brian Goetz regarding JDK 8 design decisions with the author’s own commentary to make the point that “there are good explanations for the dark side to exist.”
There are, of course, issues between newly released JDK 8 and tools built on Java. For example, in the post Hello Java 8 (and how it makes GlassFish speechless…), Cay Horstmann documents GlassFish 4 not writing any stack trace whatsoever when he had “[compiled] the WAR with the wrong version of Java.”
Although the referenced posts point out legitimate issues of concern related to some of JDK 8’s most anticipated features such as lambda expressions, streams, interface default methods, and the Nashorn JavaScript engine, I am still excited about the brave new world of Java development with JDK 8. The posts highlighted in this post are reminders to use these new features carefully and judiciously so that we enjoy the advantages they bring while mitigating as much as possible the new dangers and costs they present when used less wisely.
| Reference: | Dubious Aspects of Features of JDK 8 from our JCG partner Dustin Marx at the Inspired by Actual Events blog. |
