Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Java has long been infamous for its NullPointerException. The reason for the NPE is calling a method or accessing an attribute of an object that has not been initialized.
var value = foo.getBar().getBaz().toLowerCase();Running this snippet may result in something like the following:
NullPointerException (NPE) is the most common exception in Java. The cause of this exception is known but looks like that in most cases developers prefer to ignore it and don't take any action. I personally expect that reasons for such behavior are the following:
In this article, I'll explain what is the root of this problem and provide ways to fix that problem.
A few days ago I did a post on LinkedIn talking about the Optional class. One comment was an excellent question:
Could the use of
Optionallead to performance degradation?
A method is a contract; when we define one, we put our thoughts into it. We specify the parameters with their type and also a return type. When we invoke a method, we expect it to behave according to the contract. If it doesn’t, it’s a violation of the contract.
We deal with such a violation all the time. We invoke a method with its proper arguments, and we get a return. However, sometimes we end up getting a null, which is, in fact, a clear violation. We shouldn’t accept such a violation. If a method cannot return the value of the specified type, it should mention that in the method signature, the method may or may not be returning the value you are expecting. If we know it from the method signature, we then write our code accordingly.
I think code review is one of the best sources of inspiration. I see it as an opportunity to learn new things from other software developers sending pull/merge requests. Moreover, sometimes you may need to study a specific subject with more details regarding the under review code. Usually, this process leads to a more profound knowledge of that domain. However, there’s still another fact about code review: after a while, you face some common mistakes. Recently, I reviewed a feature in which I saw an Optional pitfall. Honestly, I had seen that issue several times in different merge requests sent by several developers (from beginners to experienced ones).
I know that there are tonnes of articles regarding Java Optional, some of which are quite useful like this one (although I have arguments against some of the cases mentioned in the article) by Anghel Leonard, the author of Java Coding Problems. I don’t want to repeat all of the contents you can simply find by googling. I intend to talk about some of the most common and least addressed pitfalls regarding Optional usage.
A very common misunderstanding, as well as bad usage, can prevail if you simply go by the dictionary and semantic definition of Optional.orElse() and Optional.orElseGet().
A smart man makes a mistake, learns from it, and never makes that mistake again. But a wise man finds a smart man and learns from him and how to avoid the mistake altogether.
Today, I would like to discuss an essential Java topic – the usage of Optional class — and compare it with an alternative from the Vavr library. Optional was initially introduced in Java 8 and defined as “a container object which may or may not contain a non-null value.”
You may also like: 26 Reasons Why Using Optional Correctly Is Not Optional
Developers utilize Optionals in order to avoid null checking in places when code execution leads to "not a result" but also to a null value, and it can, in this regard, result in a NullPointerException. In such cases, Optional offers us some fancy functionality, but not all of it was introduced in the 8th release, some features require Java 11. Another way to handle these issues is with Vavr’s Option class.
The class java.util.Optional is implemented as a single immutable concrete class that internally handles two cases; one with an element and one without. Wouldn't it have been a better choice to let Optional be an interface and have two different implementations implement that interface instead? After all, that is what we generally are taught to do in an object-oriented language.
In this article, we will learn about some of the potential arguments for the current Optional implementation. We will also learn why Streams are implemented in a different way, enabling Streams to be obtained from files or even database tables.