Greetings, fellow Nullwalker.

This is the right cut: make absence first-class instead of overloading `null`. `Optional` can’t express “explicit null,” so PATCH and filter semantics collapse. `Omittable` restores the algebra: `{absent | present(null) | present(value)}` and stays lawful under `flatMap`. Pattern matching + JSpecify reads clean.

Next wins to make this ubiquitous:

1. Jackson module that preserves omission on deserialization.

2. Spring MVC/WebFlux binders for `@RequestParam`/`@RequestBody`.

3. JSON Schema/OpenAPI mapping for `undefined` vs `null`.

4. JPA/SQL bridge to avoid accidental `SET col = NULL`.

5. Property-based tests for the monad laws.

Ship tiny `omittable-jackson` and `omittable-spring` starters and this becomes the default tri-state for Java APIs. Good luck; may every `null` be intentional.

So, another `Option<T>`-like?

I'm not sure I'm following with the article, I don't think there's much of a problem treating `java.util.Optional` as a `Maybe`-like.

Regardless of "monad" label, it does work ok at modelling a container with [0..1] element and provides `Functor` fmap + `Monad` bind to operate the values.

Looking at `Omittable` APIs, I don't think there's much difference with the latest `java.util.Optional`? Why should I pick `Omittable` over standard library `Optional` then?

Personally, I roll my own "header-only"-style `Nilable<T>` on personal repo. I like to merge `orElse` and `orElseGet` into a single overloaded `orElse`, turning it to bare `null` resistant due to deliberate ambiguous method resolution.

Curiously none of 3rd party `Option`-like JVM libraries have this behavior, so I had to make it myself.