{"id":25388,"date":"2016-07-22T11:49:34","date_gmt":"2016-07-22T11:49:34","guid":{"rendered":"https:\/\/blog.jetbrains.com\/idea\/?p=14432"},"modified":"2016-08-04T10:14:28","modified_gmt":"2016-08-04T10:14:28","slug":"java-8-top-tips","status":"publish","type":"idea","link":"https:\/\/blog.jetbrains.com\/ja\/idea\/2016\/07\/java-8-top-tips","title":{"rendered":"Java 8 Top Tips"},"content":{"rendered":"

I\u2019ve been working a lot with Java 8 code over the last couple of years, for both new applications<\/a>\u00a0and migrating existing\u00a0ones<\/a>, and it feels like the right time to write down some of the \u201cbest practices\u201d I\u2019ve found useful. I personally dislike the term \u201cbest practices\u201d as it implies a \u201cone size fits all\u201d solution, and of course coding doesn\u2019t work that way – it\u2019s down to us as developers to figure out what will work in our situation. But I have discovered I have particular preferences for Java 8 code that I find makes my life a little easier, and I thought I’d start a discussion on this topic.<\/p>\n

Optional<\/h3>\n

Optional<\/code><\/a> is a highly underrated feature, and one that has the potential to remove a lot of those NullPointerExceptions<\/code>\u00a0that can plague us. It\u2019s particularly useful at the boundaries of code (either APIs you\u2019re using or APIs you\u2019re exposing) as it allows you and your calling code to reason about what to expect.<\/p>\n

However, applying it without some thought and design can lead to one small change impacting a large number of classes, and can lead to poorer readability.\u00a0Here are some tips on how to use Optional effectively.<\/p>\n

Optional should only be used for return types<\/em>
\n…not parameters and not fields. Read this blog post<\/a> to see a pragmatic approach to using Optional. Fortunately, IntelliJ IDEA lets you turn on an inspection<\/a> to check you\u2019re following these recommendations<\/p>\n

\"Optional<\/a><\/p>\n

Optional values should be dealt with in the place they\u2019re encountered. \u00a0IntelliJ IDEA\u2019s suggestions\u00a0will prevent Optional leaking all over your code, so remember you\u00a0should deal with Optional where you found it and move swiftly on.<\/p>\n

\"Deal<\/a><\/p>\n

You should\u00a0not simply call get()<\/em>
\nThe strength of Optional is to express that this value might be empty, and allow you to cater for that case. Therefore, it’s important\u00a0to check if\u00a0there is a value before doing anything with it. \u00a0Simply calling get()<\/code> without checking isPresent()<\/code> first\u00a0is likely to lead to a null pointer at some point.\u00a0Fortunately, once again IntelliJ IDEA has an inspection to warn you\u00a0to stick to this.<\/p>\n

\"Get<\/a><\/p>\n

There is probably a more elegant way<\/em>
\nThe isPresent()<\/code> combined with get()<\/code> certainly does the trick…<\/p>\n

\"Simplest<\/a><\/p>\n

…but there are more elegant solutions. You can use orElse<\/code> to give an alternative value in the case that it’s null<\/p>\n

\"Using<\/a><\/p>\n

…or\u00a0you can use orElseGet<\/code> to tell it which method to call in the case that the value is null. This might seem the same as the above example, but the supplier method will be called only if needed, so if it’s an expensive method, using the lambda will give you better performance.<\/p>\n

\"Using<\/a><\/p>\n

Using Lambda Expressions<\/h3>\n

Lambda expressions<\/a> were one of the main selling points of Java 8. \u00a0Even if you’re not using Java 8 yet, you’ve probably got basic understanding of them by now. But they are a new way of programming within Java, and\u00a0it’s not yet obvious what is “best practice”. Here\u00a0are some guidelines I like to follow.<\/p>\n

Keep it Short<\/em>
\nFunctional programmers may be happy with longer lambda expressions, but those of us who’ve been using only\u00a0Java for many years might find it easier to keep lambda expressions to a small number of lines. You might even prefer to limit them to just a single line, and you can easily refactor longer expressions into a method.<\/p>\n

\"Extract<\/a><\/p>\n

These may even collapse down into method references. Method references may seem a bit alien at first, but it\u2019s worth persevering with them as they can actually aid readability in some cases, which I’ll talk about later.<\/p>\n

\"Collapse<\/a><\/p>\n

Be Explicit<\/em>
\nType information is missing for lambda expressions, so you may find it useful to include the type information for the parameter.<\/p>\n

\"Explicit<\/a>As you can see, this can get quite unwieldy. \u00a0So I prefer to give my parameters a useful name. Of course, whether you do this or not, IntelliJ IDEA lets you see type information of parameters.<\/p>\n

\"See<\/a><\/p>\n

and even the Functional Interface the lambda represents<\/p>\n

\"See<\/a><\/p>\n

Designing for Lambda Expressions<\/h3>\n

I think of lambda expressions as being a little like Generics <\/a>– with Generics, we use them regularly\u00a0(for example, adding type information to List<><\/code>\u00a0), but it\u2019s much more rare that we\u2019ll design a method or a class that has a Generic type (like a\u00a0Person<T><\/code>). Similarly, it feels like we\u2019ll pass lambdas around when using\u00a0things like the Streams API, but it\u2019ll be much more rare for us to create a method that requires a lambda parameter.<\/p>\n

However, if you do find yourself in this situation, here are some top tips.<\/p>\n

IntelliJ IDEA can help you introduce a functional parameter<\/em>
\nThis lets you create a parameter<\/a>\u00a0where someone will pass in a lambda rather than an Object. The nice thing about this feature is that it suggests an existing functional interface<\/a> that matches the specification.<\/p>\n

\"Extract<\/p>\n

Which leads to…<\/p>\n

Use existing functional\u00a0interfaces<\/em>
\nAs developers become more familiar with Java 8 code, we\u2019ll know what to expect when using interfaces like Supplier<\/code><\/a> and Consumer<\/code><\/a>, and creating a home-grown ErrorMessageCreator<\/code> (for example) could be confusing, and wasteful. Take a look at the function package<\/a> to see what’s already available.<\/p>\n

Add @FunctionalInterface to your functional interface<\/em>
\nIf you really do need to create your own functional interface, then tag it as such with this annotation. \u00a0It might not seem to do much, but IntelliJ IDEA will show you\u00a0if your interface doesn\u2019t match the exceptions for a functional interface. It flags when you haven\u2019t specified a method to override:<\/p>\n

\"Functional<\/a><\/p>\n

it flags when you\u2019ve specified too many:<\/p>\n

\"Functional<\/a><\/p>\n

and it\u00a0warns you if you\u2019ve applied it to a class rather than an interface:<\/p>\n

\"Functional<\/a><\/p>\n

Lambda expressions can be used for any interface with a Single Abstract Method, but they can’t be used for abstract classes that meet the same criteria. \u00a0Seems illogical, but it is what it is.<\/p>\n

Streams<\/h3>\n

The Stream API<\/a> is another one of the big selling points of Java 8, and I think we still don’t really know how much this is going to change (or not) the way we code. Here’s a mixed bag of things I’ve found useful.<\/p>\n

Line up the dots<\/em>
\nI personally prefer to line up my stream operations. You don\u2019t have to, of course, but I\u2019ve found this\u00a0helps me:<\/p>\n