Lambdas lambdas lambdas. That’s all you ever hear about when talking about Java 8. But that’s just one part. Java 8 has a lot of new features – some are powerful new classes and idioms, while others are just things that should have been there from the get-go.
I wanted to go over ten new features which I consider to be little gems definitely worth knowing about. There are bound to be at least one or two you’d like to try, so let’s get going!
- Default Methods
- Process Termination
- StampedLocks
- Concurrent Adders
- Optional Values
- Annotate Anything
- Overflow Operations
- Directory Walking
- Strong Random Generation
- Date.toInstant()
A new addition to the Java language, you can now add method bodies to interfaces (called default methods). These methods are implicitly added to every class which implements the interface.
This enables you to add functionality to existing libraries without breaking code. That’s definitely a plus. The flip side is that this seriously blurs the line between an interface, which is meant to serve as a contract, and a class which serves as its concrete implementation. In the right hands this can be an elegant way to make interfaces smarter, avoid repetition and extend libraries. In the wrong hands, we’ll soon be seeing interface methods querying this and casting it to a concrete type. Shivers….
Launching an external process is one of those things you do half-knowing you’ll come back to debug it when the process crashes, hangs or consumes 100% CPU. The Process class now comes equipped with two new methods to help you take control of unruly processes.
The first one, isAlive(), lets you easily check if the process is still up without having to wait for it. The second and more powerful one is destroyForcibly() which lets you forcibly kill a process which has timed-out or is no longer necessary.
Now here’s something to get excited about. Nobody likes to synchronize code. It’s a sure-fire way of reducing your app’s throughput (especially under scale), or worse – cause it to hang. Even so, sometime you just don’t have a choice.
There are plenty of idioms to synchronize multi-threaded access to a resource. One of the most venerated ones is ReadWriteLock and its associated implementations. This idiom is meant to reduce contention by allowing multiple threads to consume a resource while only blocking for threads that manipulate it. Sounds great in theory, but in reality this lock is sloooow, especially with a high number of writer threads.
This got so bad that Java 8 is introducing a brand new RWLock called StampedLock. Not only is this lock faster, but it also offers a powerful API for optimistic locking, where you can obtain a reader lock at a very low cost, hoping that no write operation occurs during the critical section. At the end of the section you query the lock to see whether a write has occurred during that time, in which case you can decide whether to retry, escalate the lock or give up.
This lock is a powerful tool and deserves a complete post by itself. I’m giddy with excitement about this new toy – well done!
Additional reading here.
This is another little gem for anyone working on multi-threaded apps. A simple and efficient new API for reading and writing to counters from multiple threads, in a way that’s even faster than using AtomicIntegers. Pretty darn cool!
Oh, NullPointers, the bane of all Java developers. Maybe the most popular of all exceptions, this has been around since the dawn of time. Or at least 1965.
Borrowing from Scala and Haskell, Java 8 has a new template named Optional for wrapping references that may be null. It’s by no means a silver bullet to end nulls, but more a means for an API designer to signify at the code level (vs. the documentation) that a null value may be returned or passed to a method, and the caller should prepare for it. As such, this will only work for new APIs, assuming callers do not let the reference escape the wrapper where it can be unsafely dereferenced.
I have to say I’m pretty ambivalent about this feature. On one hand, nulls remain a huge problem, so I appreciate anything done on that front. On the other hand I’m fairly skeptical this’ll succeed. This is because employing Optional requires continuing company-wide effort, and with little immediate value. Unless enforced vigorously, chances are this will be left at the side of the road.
More about Optional here.
Another small improvement to the Java language is that annotations can now be added to almost everything in your code. Previously, annotations could only be added to things like class or method declarations. With Java 8 annotations can be added to variable and parameter declarations, when casting to a value to specific type, or even when allocating a new object. This is part of a concentrated effort (along with improvements to the Java doc tools and APIs) to make the language more friendly towards static analysis and instrumentation tools (e.g FindBugs). It’s a nice feature, but much like invokeDynamic introduced in Java 7, its real value will depend on what the community does with it.
Now here’s a set of methods which should have been a part of the core library from day one. A favorite hobby of mine is to debug numeric overflows when ints exceed 2^32, and go on to create the nastiest and most random of bugs (i.e. “how did I get this weird value?”).
Once again, no silver bullet here, but a set of functions to operate on numbers that throw when overflow in a less forgiving way than your standard +/ * operator which implicitly overflow. If it was up to me I’d have this be the default mode for the JVM, with explicit functions that allow arithmetic overflow.
Iterating the contents of a directory tree has long been one of those go-to google searches (in which case you should probably be using Apache.FileUtils). Java 8 has given the Files class a face-lift, with ten new methods. My favorite one is walk() which creates a lazy stream (important for large file systems) to iterate the contents of a directory structure.
There’s no shortage of talk nowadays about password and key vulnerability. Programming security is a tricky business and prone to mistakes. That’s why I like the new SecureRandom.getinstanceStrong() method which automatically picks the strongest random generator available to the JVM. This reduces the chances of you failing to get, or defaulting to a weak generator, which will make keys and encrypted values more susceptible to hacking.
Java 8 introduces a complete new date time API. This is fairly understandable, as the existing one isn’t very good. Joda has essentially been the go-to Java date time API for years now. Still, even with the new API one big problem remains – there’s a TON of code and libraries using the old API.
And we all know they’re here to stay. So what do you do?
For this Java 8 has done something pretty elegant, adding a new method to the Date class called toInstant() which converts it to the new API. This enables you to make a quick jump to the new API, even when working with code that uses the old Date API (and will continue to do so in the foreseeable future).
Are there any features you think are missing and need to be here, or disagree with our analysis? Let us know in the comments section – that’s what it’s there for!
| Reference: | 10 Features in Java 8 You Haven’t Heard Of from our JCG partner Tal Weiss at the Takipi blog. |
Superb.. Learnt some thing new.. Thanks to this website
I took the time to read this article in detail today. Congrats to the author! Especially the fact the java.util.Date is not entirely thread-safe (as confirmed in the last mentioned post, article written by Oracle) was rather knew to me. I’ve been giving the Java 8 fundamentals training in Belgium a couple of times but will certainly refer to this article next time.