Checking for null parameters, however, is not the correct reaction to this admitted shortcoming of the type-system, because it ignores that there are actually two distinct categories of null-related issues.

The first category is the simple programming error. Errors and bugs can always happen, of course, for example, some parameter somewhere becomes null, even if the code requires a non-null reference. Java already has a mechanism to catch these types of errors by throwing a NullPointerException. Yes, in these cases, this is not a bad thing. The bug needs to be visible to be easily corrected. The second category is the problematic one.

It is when code deals with null values, often assigning meaning to the null value , like the Weld code with the conditions above. In these cases, there will be no exceptions generated; there will only be some different behavior. It wouldn't be visible if some of the parameters were null by accident, rather, there would be perhaps some business-level issue.

Instead of a clear exception to follow, this would probably require debugging or a more in-depth analysis. Beyond the obvious cost that the additional boiler-plate code introduces, the much greater cost of null-checks is that it legalizes nulls. It makes it OK to pass and receive nulls, thereby increasing the code surface where nulls can cause issues. It can also hide these issues caused by creating code that can continue to work with a null value in some form, implicitly altering the logic of the code.

In a perfect world, it should not be possible to pass or return null values, at least not in public methods. This is one area where Kotlin, Haskell, and others are clearly better designed than Java. We can, however, pretend that nulls don't exist.

The question is: is that practical? In the case of programming errors , it is very easy to find out that nulls were passed on. If there are no null-checks and no alternative paths for execution, it will sooner or later lead to a NullPointerException.

This will be clearly visible, therefore, easy to find and correct. This strategy, however, does not work if null is a legal value of some parameter or parameters. The simplest solution for these cases is to split the method into multiple ones with each requiring all its parameters.

This would transform the Weld code above where the base parameter is not required:. An alternative solution is to allow the "root" as a base parameter, in which case the method does not need to be split, and the base can be a required parameter. Sometimes, there can be more than 1 or 2 parameters in a signature that are not required. This is often seen in constructors. Constructors are just like methods, they can also be overloaded so that each one performs one single responsibility.

Java does not provide real support for default values for constructor parameters, so Telescoping constructor is one of the available options to convey that some parameters are optional in Java! The main idea behind Telescoping constructor concept is based on delegation : Each constructor calls another constructor which has more parameters! The constructor with one parameter calls the constructor with two parameters… you can chain your constructors until all optional arguments are covered to avoid code duplication!

As you can see, each constructor has different number of parameters, so basically, you have the possibility to create an instance with the combination of parameters you want! However, on the other hand, this option is considered an anti-pattern, constructors with many parameters are hard to read and maintain!

If you have 2 or 3 parameters with the same type, then you may accidentally switch their values without any compilation error! In short, a JavaBean represents a simple Java class that follows certain specific conventions about method naming, construction and behaviour:.

JavaBean convention suggests an easiest and scalable way to set optional parameters in Java! It allows to create an object using step-by-step strategy, first you need to call the default constructor to instantiate the class, and then call setXXX methods to set your object properties! Easy to read and to scale - Adding more parameters is not a big deal!

Most Java IDE can generate getters and setters for you! It creates an empty object default constructor with an inconsistent state which means the object is not fully constructed yet! JavaBean objects are mutable, so this approach is not compatible with immutable pattern. Static factory methods provide another flexibile way to create objects. Instead of using the constructor directly to create an instance, you can define a public static factory method which simply returns an instance of the class!

As we have already seen in a previous chapter, you can create multiple constructors to tackle Java optional parameters! However, it is hard to distinguish between one from another since they all have the same name.

The idea behind this approach is to create static methods with different names so that the intention of object creation become obvious and clear. You can mark your constructors private, so they can be called only from inside the class and mark the factory methods as static so that they can be invoked without instantiating the class. Each method can have a different name, unlike constructors, so this helps to clarify the way used to create an instance. One of the main downside of this strategy is that it does not scale well, it gets hard to implement and maintain if the number of optional parameters is big.

This design pattern provides a very interesting way to create a complex object. The main purpose, is to separate the construction of an object from its representation! Builder pattern is yet another approach to handle Java optional parameters!

It is a good alternative to consider in order to construct objects with optional parameters! You can simply rely on constructor overloading concept and create multiple constructors in your class to cover all the possible parameter combinations! But what if your class has too many fields? Hans-Martin Mosner 11k 1 1 gold badge 20 20 silver badges 28 28 bronze badges. Ertai87 Ertai87 5 5 bronze badges. I don't think one is worse than the other, they are basically equivalent.

But with method arguments you have an alternative: overloads. This is better. You can use a private method for the generic implementation which is called by the public methods. This way you have more control, you can just throw if the client passes null for any argument.

Add a comment. Active Oldest Votes. So why is it a bad idea? Two reasons: It is not possible in Java to indicate in the type system if null is allowed or not. The default value for an uninitialized reference is null. This means a reference can be null for two reasons: There is a bug and the value was not properly initialized It is intentionally null to indicate the lack of an optional value Since the code can't distinguish between the two cases, a bug may go unnoticed because the code cannot distinguish a bug from the legitimate value.

Improve this answer. JacquesB JacquesB That is a good point, I never thought of it that way; I've used null to represent "optional value not present" in my code a lot without thinking that, in a black box, "null" could be indication of a bug in code flow.

Matthew Matthew 1, 4 4 silver badges 8 8 bronze badges. But according to the creator of the Optional class, Optional is intended to be used only in the return value for methods, and is explicitly not intended to be used as a parameter. How does this approach not violate that constraint or at the very least, not obfuscate the code to make it look like the constraint isn't being violated when it actually is? Furthermore, in your business logic myMethod in your case , it is true you don't have an explicit null check, but you do have an implicit one inside Optional::orElse ; you're not saving anything except obfuscating away your null check to make it look like you're not doing it when you actually are; I don't understand how this solves the problem.

It's not a parameter, it's a field in a class. I guess if you really wanted, you could have the fooParam be just a Foo that may or may not be null and in getFooParam return Optional. Also, it solves the problem because the implementer of myMethod doesn't have to remember to check for null, the implementer MUST do something about the Optional and it's clearer to the caller of myMethod that the foo param is optional.

For example, let's say I have a method with 6 parameters where the last 5 are optional: foo "example", null, null, 1, null null ; Looking at that, it's not terribly easy to tell which parameter I am providing and which ones I am not.

A simple example can demonstrate this last point: Assume a function with lots of parameters like so: void drawRectangle Point center, Float width, Float height, Color fill, Color stroke, Scale xScale, Scale yScale ; An example of all the parameters filled in might look like this: drawRectangle point 3, 20 , This is a little far-fetched for something like this but bear with me for demonstrative purposes: drawRectangle null, null, JimmyJames JimmyJames I'm not sure I see how null in this case is any worse than having a method that takes a whole bunch of parameters of the same data type in the first place; you still have to cross-reference the method signature with the argument list to make sense of what's going on.

Not to say the latter isn't also a problem, but given that you are prepared to do the latter, I don't see how null really exacerbates that issue. I've added a more detailed example to help illustrate the problem. Let me start by describing two problems with Java: No distinction between nullable and non-nullable types. Secondly it's not possible to assign a nullable variable String?

Parameter Defaults Other languages also allow defaults values to be set for parameters. These can typically be used in one of two ways: Avoid the need to specify all parameters assuming the remaining parameters are defaulted Use "named" parameters to only specify the values you want to pass.

Back to Your question The primary advantage to a parameter object is that it can be passed through many levels of methods. Rafael Tavares 7 7 bronze badges. DavidT DavidT 1 1 bronze badge. All parameters in Java are pass-by-value. There's no way to have a 'non-null pointer' that points to null in Java. A reference in Java either points to an object, or it's null. The problem What is the difference between a param object with an optional field which has a "field not set" value, and a method with explicit parameters for which null is a valid value to represent "optional parameter not set", and why is one acceptable and the other not?

Well, as you said: a method with explicit parameters for which null is a valid value to represent "optional parameter not set" Therefore, you want to do something like: myPersonService. UpdatePerson , newAddress, null ; Okay, that works. Second question, what if this person gets a new job, but does not move house? Well, similarly: myPersonService. UpdatePerson , null, newEmployment ; So far, so good.

Which leads to: myPersonService. UpdatePerson , null, null ; But by applying your approach from above, how do we distinguish between not updating the address because it is null, and nullifying the employment because it is null? Tangentially: When IndexOf cannot find an occurrence, it returns The solution?

But it's a bad idea, for several reasons: This requires a reader to have perfect knowledge of all accepted values for all properties at all times, before the reader can understand exactly what is happening when you call UpdatePerson , null, null.

Which of these is being updated? Which isn't? You may change the implementation in the future, suddenly dis allowing null to be used as a valid value in the entity. ShouldBeUpdated person.