Update: Pattern matching for switch arrived in Java 21.

tl;dr

👉 switch expressions != pattern matching with switch

You are mixing up the relatively new feature of switch expressions with the still-not-released feature of pattern matching with switch.

The switch feature in Java has been evolving through 3 phases, two completed:

• ☑️ switch statement (original feature in Java 1)
• ☑️ switch expression (Java 14+)
• ❌ Pattern matching for switch, including case null (previewed in Java 17, 18, 19, & 20)

Do not conflate switch expressions with pattern matching

Classic switch

Understand that historically, the Java switch statement has been hostile to null checks. See this Question, How to use null in switch. As shown there, code such as this:

switch ( i ) {
    case null:
        doSomething0();
        break;    
}

… was not possible.

switch expressions

Fast forward to Java 14, when switch expressions was added to Java. A switch can return a value. See JEP 361: Switch Expressions.

The switch expressions feature provides the syntax seen in your first code example:

return switch ( testEnum ) {
  case FOO -> newFoo();
  case BAR -> newBar();
}

But read the JEP. No mention of null — « crickets ».

Pattern matching for switch

Fast forward further, to JEP 406: Pattern Matching for switch (Preview). Note that this is a preview feature in Java 17, not a final, officially released feature. (To understand how preview features work, read JEP 12: Preview Features.)

👉 In that JEP 406, notice its second goal: Allow the historical null-hostility of switch to be relaxed when desired.

Now search that page for “null” — 73 hits! That page explains the former policy of the Java language:

Traditionally, switch statements and expressions throw NullPointerException if the selector expression evaluates to null …

Notice the mention of statements, the original switch syntax, and additionally expressions, the new syntax used in your code. In both cases, null check was forbidden.

That page goes on to explain the changes that motivate the inclusion of support for null checks. Read the JEP for well-written details.

👉 The upshot is that you can use case null in a switch in Java 17 — but only if you go out of your way to enable the preview feature.

Arrived in Java 21

This feature arrived in Java 21. See JEP 441: Pattern Matching for switch.

Example

Let's try this code example. Notice how we use plain old syntax here, without the ->. The arrow operator is not related to our discussion here.

String x = null;
switch ( x )
{
    case "starburst":
        System.out.println( "Is starburst." );
        break;
    case null:
        System.out.println( "Whoops, null." );
        break;
    default:
        System.out.println( "Some other value found." );
        break;
}

You can try changing your eclipse configuration first rather than using a plugin. Try setting Windows > Preferences > Java > Compiler > Errors/Warnings > Potential Programming Problems > Potential Null Pointer Access to anything besides ignore.

As a side note, always try to use a defensive programming approach if you feel like the code you're writing has many potential exception/error courses.

This to me sounds like a reasonably common problem that junior to intermediate developers tend to face at some point: they either don't know or don't trust the contracts they are participating in and defensively overcheck for nulls. Additionally, when writing their own code, they tend to rely on returning nulls to indicate something thus requiring the caller to check for nulls.

To put this another way, there are two instances where null checking comes up:

1. Where null is a valid response in terms of the contract; and

2. Where it isn't a valid response.

(2) is easy. As of Java 1.7 you can use Objects.requireNonNull(foo). (If you are stuck with a previous version then assertions may be a good alternative.)

"Proper" usage of this method would be like below. The method returns the object passed into it and throws a NullPointerException if the object is null. This means that the returned value is always non-null. The method is primarily intended for validating parameters.

public Foo(Bar bar) {
    this.bar = Objects.requireNonNull(bar);
}

It can also be used like an assertion though since it throws an exception if the object is null. In both uses, a message can be added which will be shown in the exception. Below is using it like an assertion and providing a message.

Objects.requireNonNull(someobject, "if someobject is null then something is wrong");
someobject.doCalc();

Generally throwing a specific exception like NullPointerException when a value is null but shouldn't be is favorable to throwing a more general exception like AssertionError. This is the approach the Java library takes; favoring NullPointerException over IllegalArgumentException when an argument is not allowed to be null.

(1) is a little harder. If you have no control over the code you're calling then you're stuck. If null is a valid response, you have to check for it.

If it's code that you do control, however (and this is often the case), then it's a different story. Avoid using nulls as a response. With methods that return collections, it's easy: return empty collections (or arrays) instead of nulls pretty much all the time.

With non-collections it might be harder. Consider this as an example: if you have these interfaces:

public interface Action {
  void doSomething();
}

public interface Parser {
  Action findAction(String userInput);
}

where Parser takes raw user input and finds something to do, perhaps if you're implementing a command line interface for something. Now you might make the contract that it returns null if there's no appropriate action. That leads the null checking you're talking about.

An alternative solution is to never return null and instead use the Null Object pattern:

public class MyParser implements Parser {
  private static Action DO_NOTHING = new Action() {
    public void doSomething() { /* do nothing */ }
  };

  public Action findAction(String userInput) {
    // ...
    if ( /* we can't find any actions */ ) {
      return DO_NOTHING;
    }
  }
}

Compare:

Parser parser = ParserFactory.getParser();
if (parser == null) {
  // now what?
  // this would be an example of where null isn't (or shouldn't be) a valid response
}
Action action = parser.findAction(someInput);
if (action == null) {
  // do nothing
} else {
  action.doSomething();
}

to

ParserFactory.getParser().findAction(someInput).doSomething();

which is a much better design because it leads to more concise code.

That said, perhaps it is entirely appropriate for the findAction() method to throw an Exception with a meaningful error message -- especially in this case where you are relying on user input. It would be much better for the findAction method to throw an Exception than for the calling method to blow up with a simple NullPointerException with no explanation.

try {
    ParserFactory.getParser().findAction(someInput).doSomething();
} catch(ActionNotFoundException anfe) {
    userConsole.err(anfe.getMessage());
}

Or if you think the try/catch mechanism is too ugly, rather than Do Nothing your default action should provide feedback to the user.

public Action findAction(final String userInput) {
    /* Code to return requested Action if found */
    return new Action() {
        public void doSomething() {
            userConsole.err("Action not found: " + userInput);
        }
    }
}

Eclipse has a built in list of a few methods which it knows will not return. This includes the JUnit assertNotNull but does not include fail.

Eclise bug 382069 describes this support.

Have a look at Optional. Using the sample provided, the following can throw a NPE if any of the methods called returns a null value:

String version = computer.getSoundcard().getUSB().getVersion();

To avoid that or excessive if (x != null) checks, using Optional you can use:

String name = computer.flatMap(Computer::getSoundcard)
                          .flatMap(Soundcard::getUSB)
                          .map(USB::getVersion)
                          .orElse("UNKNOWN");

No, a null check is not needed before using instanceof.

The expression x instanceof SomeClass is false if x is null.

The Java 11 Language Specification expresses this concisely in section 15.20.2, "Type comparison operator instanceof". (Java 17 expresses this less concisely, after the introduction of instanceof pattern matching.)

"At run time, the result of the instanceof operator is true if the value of the RelationalExpression is not null and the reference could be cast to the ReferenceType without raising a ClassCastException. Otherwise the result is false."

So if the operand is null, the result is false.

For Eclipse Luna, the development effort was focused on the "typical" combinations:

• Java 7 and declaration annotations
• Java 8 and type annotations

In this version the combination Java 8 and declaration annotations (what is requested in this question) was not fully implemented. This has been fixed via https://bugs.eclipse.org/bugs/show_bug.cgi?id=435805

The fix is available in milestone builds towards Eclipse Mars since M4.

OTOH, I can only encourage projects using Java 8 to upgrade to type annotations for much greater expressiveness - enabling much more precise null type checking.

Perhaps you are having an old eclipse version. My eclipse generates this:

if (this == obj)
    return true;
if (obj == null)
    return false;
if (getClass() != obj.getClass())
    return false;

Method 4 is best.

if(foo != null && foo.bar()) {
   someStuff();
}

will use short-circuit evaluation, meaning it ends if the first condition of a logical AND is false.