No need to wait - Java 8, it's great

NetBeans 8 beta suggesting to use a simpler lambda expression as listener
NetBeans IDE 8 automatically suggests to use Java 8 lambda expressions

Java 8 is to be released soon. The current schedule predicts release in the middle of March, but you should notice that the recent postponements have been due to the various webstart related security enhancements. For web developers, it has practically been ready for the whole autumn already.

I have been hacking with Java 8 lately to share some insights with all you Vaadin enthusiasts. In this blog entry I’ll not try to cover everything that is new in Java 8, but the most essential enhancements that I think are relevant for all Vaadin users.

Java 8 means largish enhancements to both JVM and language. The good thing is that changes are mostly backwards compatible, especially if you are not working with low level libraries. For example with core Vaadin, I haven’t found any issues so far.

Still, although the core Java 8 is practically production ready, I wouldn’t suggest to try Java 8 in your enterprise projects with tight deadlines today. During my exercise, I found Java 8 as a JRE already to be superior to its older sisters*, but dealing with new Java 8 bytecode still seems to be the culprit for some libraries and servers. E.g. I fought with my favorite test server for quite a while, just to notice its annotation processing library doesn’t support Java 8 byte code without hacks yet *.

Although some library and server developers still have things to do with their Java 8 support, I sincerely suggest to start learning the goodies of Java 8. Also, in less critical systems, I wouldn’t be afraid to start using it in production. A combination of tools I found working well:

  • Java 8
  • NetBeans IDE 8.0 Beta (7.4 also supports Java8, but 8 has more code converters and Java hints)
  • Latest Vaadin plugin
  • GlassFish Server 4 (bundled with NetBeans IDE)

Lambdas will clean your listener code

Java has never tried to minimize your loc count. With good typing and nice code completions in IDEs, you don’t really need to minimize the amount of code you write. Maintainability and readability is commonly way more important than the amount of code. Still even, hardest Java fanatics have to confess that lots of keywords and symbols don’t necessary improve your code quality.

Lambda support is one of the most visible enhancements in Java 8. In Vaadin developers’ daily work, lambdas mean a cleaner syntax for inline event listeners: any single method interface can now be expressed with a shorter lambda expression. From a library developers POI, this is a great change. Most commonly there are no changes needed to the libraries. Let me repeat myself: most core Vaadin API’s and add-ons can take advantage of lambdas today.

As where previously an inline click listener for a Button looked like this…

 button.addClickListener(new Button.ClickListener() {
    public void buttonClick(ClickEvent event) {
        // Your code here

… it can now be expressed like this…

    // Your code here

… or as a one-liner like this:


 button.addClickListener(e->System.out.println("Yes, it works"));


Method name listeners, welcome back

If you have been following the Vaadin development for as long as I have been involved with it, you know that we once had an API that allowed the usage of method names together with the target object as “listeners”. It is arguable a handy way to hook your logic to views, but on the other hand it is a very risky place to introduce bugs. Also, you’ll lose all the cool refactoring support that IDE’s provide. So, we finally deprecated the feature in 2013 in Vaadin 7. IMO we should have deprecated them already in 2008.

A year later, in 2014, method name listeners are making their comeback. This time without compromises nor intervention from our R&D team. Now with Lambda enhancements in Java 8, you can reference a method from an object, with a compatible signature, and use it as a listener. E.g. hooking your view to a controller might look like this in the future:




More lambda goodies

One thing to note is that lambda expressions are not a shorthand for inner classes. They are a bit larger enhancement to the language and JVM than they might seem at first sight. When starting with lambdas, variable scoping is something where you should be awake. In most cases things will just work, also in cases where it previously might have not. If you are an experienced Javascript hacker, you could consider lambdas as closures.

A short example here might tell more than a longish technical explanation:

 LocalDateTimeField field = new LocalDateTimeField();
    /* Look Ma, no "final" required for the field variable! */
    Notification.show("Value now:" + field.getValue());


If you have worked with Java in any non-trivial project, you must know something about the history of handling dates and times in Java. I know that Date and time calculations are not easy, but still, Java has a bad history in this area. So bad that in many Java projects such a generic thing, handling dates, needs a third party helper library. Yes, that is JodaTime.

Now, in Java 8, it finally seems to contain a date handling library whose quality is in par with the rest of the JDK libraries. At least I haven’t heard too much bad about the new API’s yet.

To get started with the new date and time types, I started a new add-on project called java8date. Although I can’t really praise the core Vaadin DateField either, I based my initial solution on it and on some custom field magic. The first component in my add-on is a field for LocalDateTime, but I hope to find time to add support for other types as well.

Use the add-ons github page for feature requests, patches for other types and bugfixes. I’ll be more than happy to pull in your contributions!

Other changes in Java8

This was just a scratch on the surface about enhancements in Java 8. There are for example default methods for interfaces, big improvements to collections and their parallel processing. All the new changes don’t directly affect working with Vaadin API’s, but they are of course essential improvements that make building Vaadin applications (with Java) smoother. If you come up with other goodies Java 8 provides for Vaadin usage, please let us all know.

Big thanks to Oracle and other Java 8 developers, your contributions have made also Vaadin a much better tool!

Matti TahvonenMatti Tahvonen is a Vaadin "R&D veteran" who has been working with our products for over 6 years. His current responsibility is to keep you up to date with latest and greatest Vaadin related technologies. You can follow him on Twitter – @MattiTahvonen

It should be noted that closed-over local variables in lambdas still have to be "effectively final"; that is, they're only assigned to once. This restriction may be removed in the future.

Posted on 1/21/14 8:03 AM.

Here is a Java 8 version of our standard addressbook example: https://github.com/vaadin/addressbook/tree/java-1.8

Posted on 1/21/14 4:37 PM.

These new features looks great to simplify code and make it more readable.
But I think we still need to wait for a 8.0.1 release of java until we use these features in productive environments.

As with all software, the X.0 releases have a tendency to have some unwanted features, which then get corrected in the weeks/months.
So for productive environments I think we need to wait at least until end summer 2014 before we can go live with java 8.

But of course, for new projects with a release date in autumn 2014, GO for Java 8

Posted on 1/23/14 8:55 AM.

Heh, the chicken and egg problem with x.x.0 releases. Almost nobody ever tries beta/alpha/whatever-pre-release software -> x.x.0 becomes the true beta release :-)

Posted on 1/23/14 2:52 PM in reply to André Schild.

And, conversely, those who *do* use betas and alphas always seem to do so in production...

Posted on 1/23/14 2:55 PM in reply to Matti Tahvonen.

This is slightly misleading. Even though you can use JDK 8 to compile code, you still must set compliance level to 1.6, so basically you can not use any JDK 8 features in your code (at least with Eclipse, even though Eclipse 4.3.2 does support JDK 8 with feature patch)?

Posted on 3/20/14 5:12 PM.


AFAIK this is by no means misleading. You only need to use 1.6 if your server is using very outdated JRE. Vaadin or servers do NOT require 1.6! At least it should have 1.7 today, but now that Java 8 is out, you can safely start looking into using it on server as well. I have been running a server on Java 8 for almost half year now without issues.

Some servers still have some issues with Java 8 byte code though. I have been using Jetty 9, but for it I needed to update ASM library to version 5. So I of course suggest to test the setup before going into production.

I suggest to update both your servers JRE and your server software at once. You'll enjoy your daily work much more after that ;-)


Posted on 3/20/14 5:33 PM in reply to Mario Grgic.

There is a point in every enterprise web application project when the scalability of the application under development is wanted to be measured. There are several reasons for why scalability tests
Vaadin TestBench is a browser automation tool, suited for creating UI level tests for Vaadin applications. It is based on Selenium 2, which means that all features of Selenium 2/WebDriver are also
Servlet 3.0 is awesome, so is CDI . They work well and are a joy to set up. Even adding the Vaadin Navigator to the mix isn’t an issue, since you can use the CDIViewProvider to maintain the
A bit over a year ago we released Vaadin 7 renewing the framework inside out. Then came push support with 7.1 . Now what? Let’s take a look into the future. First off, we do not see
UPDATE April 2nd 2014 : This was an April fools joke. We thank all that shared the joke with us in social media and all other places and made the laugh for the day. Thanks for the hundreds of
Showing 1 - 5 of 100 results.
of 20

See all blog entries
Subscribe to this blog