Arguably yes, but that doesn't stop people using it.

Basically Java had nulls from the start. A decade or so later some people who didn't like nulls introduced their own Optional type, as a third-party library. Enough people liked it that Optional was added to Java's standard library.

But as it's just an object, it can be null. Some null avoidance enthusiasts also use third-party @Nullable and @NotNull annotations, which some automated code checking tools will attempt to verify during compile/test.

It gives you the ability to treat nulls as something-to-fix.

In a team without Optionals, every time you touch a null that you didn't expect, you have to decide "Is this deliberately null, or was it a mistake?" Without that knowledge, you don't know whether your code should assert against the null, or allow it to pass through as a valid value.

With Optionals, it becomes much simpler to cut through that nonsense. A null is a bug and you fix it (with the exception of json at the boundaries of your system, etc.) If you do find a value where you change your mind about its nullability, changing it to/from Optional will give you compile errors in exactly those other parts of the code that you now have to check/change.

Yup. Your IDE will likely highlight it as an issue, but it's totally legal to return a null Optional. There's nothing special about it, it's just a wrapper class.

Kinda.

Every non-primitive is nullable in Java. Adding Optional doesn't/can't change that.

You can have a gentlemen's agreement to prefer None to null.

It doesn’t defeat the problem in theory, but in my experience it does in practice. I’ve never come across an NPE on a nullable reference even in development - it would have to be the result of a really fundamental misunderstanding of the concept.

YMMV. Obviously it depends on your teammates.