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

[Red IO]

I don't see how Either for exceptions is any more or less coloring than
optional is for null. The only fundamental difference is that we currently
have no easy way to convert between Either and Exceptions while we have one
for null and optional. The ability to wrap the conversation in a method is
locked behind catch (T t) not working because of type erasure. Otherwise
converting a throwing function to an either and back would be as simple as
doing the same for optional. The optional currently being even worse as the
optional variable could be null defeating its purpose (a different topic).
Introducing an Either/Result type and adding supportive syntax/library
support for it on a level of optional could join the rift to streams and
other exception hostile apis without introducing any new problems or
coloring as you can just "either.orThrow()" an either and
"Either.of(obj::throwing)" on the other side. (strawman functions) Sure
compared to optional we are required to wrap the call and not just the
result which introduces issues with the Java function type system
(Either.of would either only allow suppliers or havs a lot of overloads)
but otherwise I see adding something like this as an absolute win in terms
of Java and the jdk. And I don't see the coloring issue you describe. The
only thing in java that is actually coloring is rather a method throws a
checked exception or not which is the core problem trying to get addressed
here. A return type can be anything it's not changing how and where a
function can be called. A throws declaration is. Also result types aren't
something new in Java. Look at Java sql. It uses a result type for parsing.

TL;DR
I don't think this introduces coloring on the opposite it would solve a
coloring issue in Java.

With great regards
RedIODev

On Sun, Feb 22, 2026, 23:04 Remi Forax <forax at univ-mlv.fr> wrote:

> [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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260223/164e3f38/attachment.htm>