I had written a code of which a rough snippet is as follows:

boolean isCalledFromAction = Optional.ofNullable(requestParams.get(IS_CALLED_FROM_ACTION))
                             .map(val -> true)
                             .orElse(false);

My team lead said to always use existing classes and insisted to use Boolean class like below:

boolean isCalledFromAction = Optional.ofNullable(requestParams.get(IS_CALLED_FROM_ACTION))
                             .map(val -> Boolean.TRUE)
                             .orElse(Boolean.FALSE);

My question is I see Boolean.TRUE will make unnecessary a Boolean type object. When to use true and when to use Boolean.TRUE? Why in first place, Boolean.java class contains a wrapper object for true and false? I mean, they have auto-boxing so they can directly do like Boolean x = true; instead of Boolean x = Boolean.TRUE.

I have read answers on existing questions on SO related to performance but here I am interested in their usage scenarios.

Constant, just one immutable object

You asked:

My question is I see Boolean.TRUE will make unnecessary a Boolean type object.

No, multiple objects are not created.

As commented by Culloca, Boolean.TRUE is a constant, referring to a singe object instantiated once when the class loads. As an immutable object, there is no need to have more than one.

Let’s look at the implementation found in the open source code at the OpenJDK project.

public static final Boolean FALSE = new Boolean(false);

The static means an instance is created when the class loads. The final means the reference named FALSE will never be re-assigned to another object. So one, and only one, object.

Avoid excessive auto-boxing

You are right to be concerned about unnecessary auto-boxing. Boxing is not magic; it takes CPU cycles to execute.

Going out of your way to use Boolean.FALSE where you know the primitive false is needed is pointless and a bit silly.

Such a practice is often harmless. If the code is infrequently executed, then you’ll see no significant impact on performance. And in some situations I would guess that the compiler might optimize away the boxing, though that is just a guess on my part.

FYI… Work is underway by the Java team to blur the sharp distinction between primitives and objects created by Java’s two parallel type systems. So the nature and impact of boxing may change in future versions of Java.

No need for Optional

Your code is overly elaborate.

You commented:

The type returned by requestParams.get(IS_CALLED_FROM_ACTION) is a string. If it is not null, I want to set isCalledFromAction to true.

Change this:

boolean isCalledFromAction = Optional.ofNullable(requestParams.get(IS_CALLED_FROM_ACTION))
                             .map(val -> true)
                             .orElse(false);

… to use Objects.nonNull:

boolean isCalledFromAction = 
    Objects
    .nonNull ( 
        requestParams.get( IS_CALLED_FROM_ACTION ) 
    ) ;