Java 8 is expected in September 2013. It will include a number of deferred features that were originally planned for Java 7 and also some new ones. Will this be the new release that developers have really been clamoring for? In this series, I will focus on a few features that have been anxiously awaited and discuss what I think they might mean to the community.

For a full rundown of JDK enhancement proposals that were accepted and funded, check out Or, go and download the JDK 8 Early Access and start playing with the new features now.

Last time, I introduced Project Lamdba. This time, I will discuss:

  • Date and Time (JSR 310)
  • Type Annotations (JSR 308)
  • Metaspace replacing PermGen (JEP 122)
  • Project Nashorn Javascript Engine (JEP 174)

Date and Time (JSR 310)

In the beginning, there was java.util.Date. These are numeric timestamps containing both a date and a time, not easily internationalized. The Date class was littered with properties having bizarre offsets. For example, month and hours were zero-based, days were one-based and years had 1900 as the offset. Clear as mud. Later, Java 1.1 added java.sql.Date to support SQL via JDBC, inheriting from java.util.Date, but it was different and confusing for many. Later still, java.util.Calendar was contributed by IBM, mainly to support internationalization and to offer flexibility. This is the pain that many developers have lived with ever since – it is very complex. There is often a great deal of setup and planning to solve even simple date problems. And there were other issues too. For example, both Date and Calendar are mutable, meaning they often require cloning.

To solve these and other problems, Stephen Colebourne released Joda-Time in 2005 – a fantastic library with a goal of making dates and times bearable to work within Java. Software everywhere added this library to their deployments and started avoiding the Java built-in options. This has been a boon, however, some great third party libraries don't support Joda-Time so the pain of conversion between formats appears in many developer solutions.

Fast forward to 2013 and Java 8 promises to replace all of this with a new standard library that borrows heavily from Joda-Time. The spec lead for this new library is none other than Colebourne himself. Rather than just drop in Joda-Time as it exists, the decision was made to rectify some known design flaws, as blogged about in Why JSR-310 isn't Joda Time. The new API splits classes into the two concepts of continuous and human time. Continuous time is based on UNIX time, a single incrementing number representing either a point in time (Instant) or an amount of time passed (Duration). Human time focuses on units of time we use in our daily lives such as day, hour, minute and second. It also takes into account time zones and descriptive periods like "4 months and 12 days."

Colebourne has said that Joda-Time will be updated with interfaces from JSR-310 and that it will be possible to have both libraries in the same application, providing interoperability. This will provide an upgrade path for Joda-Time users, but the push will be to move directly to the Java 8 built-in library.

For the community of users currently on Joda-Time (just about everyone), this is not big news. They have been happy using a well-supported, easy-to-use library and ignoring the pre-Java 8 Date and Calendar classes as much as possible. I would see little impact for existing software and that new software will probably use the new functionality and cut down on external libraries by one. For users who somehow were not aware of Joda-Time, their date and time handling capabilities are about to get a huge improvement.

Type Annotations (JSR 308)

Java Annotations were released for use using the apt tool in Java 5 and integrated into the compiler in Java 6, when they really took off. Programmers have unquestionably taken advantage of these, writing annotations on type names in variable, method and class definitions for framework configuration or compiler and IDE code quality checks. Annotations have helped developers avoid boilerplate, excess XML configuration and have moved some basic errors and warnings from runtime to compile-time.

The new functionality promises to allow annotations on type uses, not only declarations, allowing error detection to strengthen the Java built-in typing. This should bolster checks for errors such as null pointers, data side effects, race conditions, information leakage and non-internalized strings.

Interestingly, pre-Java 8 users will also be able to tap into this functionality by simply writing their new annotations in comments and using a Type Annotations compiler designed to recognize them. This compiler will produce java-compatible byte code.

Lots more information is available on the OpenJDK Type Annotations page, and the University of Washington Computer Science and Engineering folks have put up a helpful page too.

Annotations have been a game-changer, and are now leveraged heavily. It will be a natural extension to start using these new annotations to provide more precise type control at compile-time and reduce silly bugs. I think these will be commonplace. Sadly, the language is getting less and less readable with the introduction of many of the features in Java 8, and this is no exception. Take a look at this. Fill up a class with lines like this and we'll start asking: What are we coding here again?

<code>@NotEmpty List&lt;@NonNull String&gt; strings = new ArrayList&lt;@NonNull String&gt;();</code>

Someone coming from Java 4 or 5 may not find much readable code in a Java 8 codebase. And no, that's not a rarity; there are still plenty of enterprises out there running Java 4 or 5 deployments.

Metaspace (JEP 122)

<code>java.lang.OutOfMemoryError: PermGen space</code>

If you've ever seen this (and I bet you have), you'll know the pain. You tuned the garbage collector, you set up the heap, you stress tested the app, but after you go live, and after you redeploy your app a few times… BOOM. The app becomes unresponsive and this line is left in your log file.

The Permanent Generation in the Hotspot VM stores class metadata, interned strings and class static variables. Applications with large numbers of these items that didn't carefully manage references to them often encountered a situation where the garbage collector could not clean up the memory. Continual redeployments of applications would then create these items again, chewing up memory until limits were hit and the JVM crashed.

Java 8 is doing away with the Permanent Generation from the Hotspot VM entirely, which means doing away with the tuning and limiting the crashing. Some of the contents will be moved to the heap, some will be stored in native memory. Java 8 introduces a new "Metaspace" memory allocation model that by default is limited by the amount of native memory available and will resize dynamically depending on runtime demand. Tuning and limiting will still be possible in order to affect a reasonable frequency of garbage collection and to avoid native or heap memory waste.

Pierre-Hughes Charbonneau has done a great detailed write-up showing the changes here.

This is a great step forward and will relieve a lot of pain for those new to the JVM, and make things easier for experienced application deployers. Existing PermGen JVM flags will be ignored by the Java 8 JVM so everybody who makes the JRE upgrade will be automatically adopting the Metaspace model.

JavaScript (JEP 174)

JavaScript is big. Most of the focus is on the browser with JQuery and other libraries of its ilk. However, there has been a spike in interest on server-side solutions such as Node.js. Project Nashorn, due for release in Java 8 will allow JavaScript to be embedded in Java applications and to be used to develop standalone server-side JavaScript applications.

There is currently such an option already available with the Rhino engine, however, early estimates show that Nashorn will be five times faster with 1/5 the footprint. Nashorn also changes the meta-object protocol, which simplifies the interface between Java APIs and JavaScript and enables seamless interaction. Because Nashorn will comply with ECMAScript 5.1 standards, many users should be able to make the move from Rhino with minimal complications. There are, however, JavaScript 1.7 features in Rhino that may not be natively supported with Nashorn in the first release.

If you're using JavaScript on the server side, or planning to, this is big news. However, most JVM users probably aren't. I guess the best way to sum up this improvement is that if you know about it, you're thrilled; if you don't know about it, you don't care.

Next Time

Please tune in later for the third and final post, where I’ll discuss Project Jigsaw, the effort to bring full modularization to Java, something that was originally planned for a Java 7 release, delayed to Java 8, and just this past month, deferred again until Java 9.


Topics: Languages

Leave a Reply