[SPAM] Question about introduction of Either/Result like type to the Java language

[Remi Forax]

[This is my answer, not an official answer]

Hello,

TLDR;
Java is fundamentally about being able to compose libraries freely,
and you are proposing to add a new way to do function coloring [1], so No !

---

There is a deep irony in this proposal:

- you want a JDK standard Either because the current ecosystem is fractured.
  Multiple libraries use their own custom Either types, making them impossible to compose.

- the reality is that by adding Either to the JDK, you don't solve fragmentation, you evolve it.
  It will create a permanent schism between the Exception-based world and the Either-based world.
  So more incompatible libraries.

Either is also an invitation to Function Coloring.

In Rust, Result (their Either) is a perfect fit. Rust is a closed-world language where function coloring is a necessary tool for tracking memory safety and variable liveness.

However, Java has spent the last decade moving in the opposite direction. While other languages embraced async/await (another function coloring), Java spent years of engineering effort on virtual threads specifically to avoid coloring. 

Adding a manual propagation mechanism like Either in the JDK would be a step backward—reintroducing the very color that the project Loom worked to erase.

regards,
Rémi

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/


----- Original Message -----
> From: "mfejzer" <mfejzer at mat.umk.pl>
> To: "amber-dev" <amber-dev at openjdk.org>
> Sent: Sunday, February 22, 2026 9:45:05 PM
> Subject: Question about introduction of Either/Result like type to the Java language

> Hello,
> 
> I’d like to ask what you think about the introduction of an
> Either/Result-like type like type to the Java language?
> 
> Some attempts to write functional-like code in Java encounter no
> standard implementation of Either/Result-like type. Such type is usually
> used for explicit failure handling without exception usage, and is
> present in some other languages. Lack of such type in Java causes
> creation of many ad-hoc implementations which behave slightly
> differently.
> Examples:
> *
> https://github.com/vavr-io/vavr/blob/main/vavr/src/main/java/io/vavr/control/Either.java
> *
> https://github.com/functionaljava/functionaljava/blob/series/5.x/core/src/main/java/fj/data/Either.java
> *
> https://github.com/aol/cyclops/blob/master/cyclops/src/main/java/cyclops/control/Either.java
> *
> https://github.com/resilience4j/resilience4j/blob/master/resilience4j-core/src/main/java/io/github/resilience4j/core/functions/Either.java
> *
> https://github.com/kusoroadeolu/ferrous/blob/main/src/main/java/io/github/kusoroadeolu/ferrous/result/Result.java
> Introducing this type to the Java language would provide a standard
> implementation, allowing its use without depending on third-party
> libraries.
> 
> Sketch, based on example from ferrous library:
> - java.util.Result<F,S>, sealed interface permitting Success and Failure
> records,
> - records: Success<F,S>(S successValue), Failure<F,S>(F failureValue),
> - available methods: success/failure factories;
> map/flatMap/mapFailure/flatMapFailure; fold; peek/peekFailure;
> consume/ConsumeFailure etc.
> 
> Non-goals:
> - Replacing exceptions
> - Extending language syntax
> - Introducing additional functional programming concepts (Monads, Optics
> etc)
> 
> Kind regards,
> Mikołaj Fejzer