Top Tips for Java 8 Development

I have been coding in Java 8 for a few years, both for new applications and migrating existing applications, and it felt like it was time to write about some "best practices" that I have found very useful. I personally don't like the term "best practices" because it implies a "one-size-fits-all" solution, and that's not how coding works - we need to discover for ourselves what solutions work. But I found some options in Java 8 code that can help us, let's take a look.

1.Optional

Optional is a seriously underrated feature and has the potential to remove a lot of NullPointerExceptions that plague us. This is particularly useful within code boundaries (either the API being used or the API being exposed) because it allows you and your calling code to reason about what to expect.

However, applying Optional without thought and design may result in affecting a large number of classes and may result in worse readability. Here are some tips on how to use Optional effectively.

Optional should only be used for return types

... not parameters, not fields. Fortunately, IntelliJ IDEA lets you turn on a check to see if you are following these recommendations.

Optional values ​​should be handled where they are encountered. IntelliJ IDEA's suggestions will prevent Optional leaks in your code, so remember to handle Optional wherever you find it and act quickly.

You should not simply call get()

The function of Optional is to express that the value may be empty and let you deal with this situation . Therefore, be sure to check if there is a value before doing anything with it. Simply calling get() without first checking isPresent() may result in a null pointer at some point. Fortunately, IntelliJ IDEA also has checks to remind you of this.

There may be a more elegant way

Combined with get()isPresent()Of course it will Great...

#...but there are more elegant solutions. You can use orElse to give an alternative in case the value is null.

...or you can use orElseGet to indicate which method to call if the value is null. This seems to be the same as the example above, but the supplier method will only be called when needed, so if this is an expensive method, there will be better performance using a lambda.

2. Use Lambda expressions

Lambda expressions are one of the main features of Java 8. Even if you haven't used Java 8 yet, you probably have a basic understanding of them by now. They are a new way of programming in Java, and it's not yet obvious what "best practices" are. Here are some guidelines I like to follow.

Keep it short

FunctionalProgrammerswill be happier with longer lambda expressions, but those who have been immersed in Java for many years People may find it easier to keep lambda expressions to just a few lines of code. You might even prefer to limit it to a single line of code, and you can easily refactor longer expressions into a method.

These may even become method references. Method references may feel a little unfamiliar at first, but there is actually value in sticking to method references because they aid readability in certain situations, which I will discuss later.

Explicit

Type information is missing from lambda expressions, so you might find it useful to include type information for parameters.

As you can see, this time it got pretty clumsy. So I prefer to give the parameters a useful name. Of course, whether you have done this or not, IntelliJ IDEA allows you to see the type information of the parameters.

Even the functional interface represented by lambda:

3. Design for Lambda expressions

I think lambda expressions are a bit like generics - along with generics, we often use them (for example, adding type information to a List<>), but preferably we can design a method or a method with generics A class of type (e.g. Person<T>). Likewise, when using something like the Streams API, we would pass a lambda expression, but even better is to create a method that requires a lambda parameter.

But if you find yourself in this situation, here are some great tips.

IntelliJ IDEA can help you introduce functional parameters

This allows you to create a parameter where someone would pass a lambda instead of an Object. The benefit of this feature is that it shows that the existing functional interface matches the specification.

This results in...

Using existing functional interfaces

As developers become more The more familiar we are with Java 8 code, we know what happens when using interfaces like Supplier and Consumer, and how creating a local ErrorMessageCreator (for example) can be confusing and wasteful. Take a look at this package to see what is already available.

Add @FunctionalInterface to functional interface

If you really need to create your own functional interface, then mark it with this annotation as such. This may not seem to have much effect, but IntelliJ IDEA will tell you when your interface cannot match the exceptions used for functional interfaces. When you do not specify a method to override, it will flag:

When you specify too many methods, it will flag:

And if you apply it to a class instead of an interface, it will warn you:

lambda expressions can be used for Any interface with a single abstract method, but they cannot be used with abstract classes that meet the same criteria. Seems illogical, but that's what it is.

4.Stream

The Stream API is another big feature of Java 8, and I think we really don’t know how much it will change the way we code. Here are some things I found helpful.

Queue dot operator

I personally prefer to queue my stream operations. Of course, you don't have to do this, as I found it helpful to do this:

• See at a glance what operations I have

• Debugging Easier (although IntelliJ IDEA does provide the ability to set breakpoints on any number of lambda expressions in a line, splitting to different lines makes it simpler)

• Comment actions

• Easily insert peek()for debugging or testing

#Also, in my opinion, it's neater. If we follow this pattern, we don't gain much in terms of reducing lines of code.

You may need to adjust your formatting settings to align the dot operators.

Using method references

Yes, it does take a while to get used to this strange syntax. However, if used correctly, it does increase readability. See:

compared to the helper methods on the (relatively) new Objects class:

The latter code is more clear about which values ​​​​are to be saved. IntelliJ IDEA will usually let you know when a lambda can be collapsed into a method reference.

When iterating over a collection, use the Streams API

...or the new collection methods like forEach when feasible. IntelliJ IDEA's advice to you is:

Generally, using the Streams API is more clear than the combination of loops and if statements. For example:

IntelliJ IDEA suggests that this can be refactored to:

Performance testing I did shows this Refactoring is surprising - it's not always predictable whether performance will stay the same, improve, or get worse. As always, if performance is key in an application, measure it before committing one style to another.

Use loops when iterating over arrays

However, using Java 8 doesn’t necessarily mean you have to use streams and new collection methods everywhere. IntelliJ IDEA will suggest converting to a stream, however, this does not mean you have to answer "yes" (remember that the check can be suppressed or turned off).

In particular, looping over small arrays of primitive types will almost certainly be used for better performance and probably (at least for Java developers new to streams) more readable.

#As with any technique, the rules are not hard and fast, but you should decide whether to use the Streams API as much as possible or still use loops for some operations. In short, be consistent.

Finally

The above is the content of the top Java 8 development skills. For more related content, please pay attention to the PHP Chinese website (m.sbmmt.com)!