<div dir="auto">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).<div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">TL;DR</div><div dir="auto">I don't think this introduces coloring on the opposite it would solve a coloring issue in Java. </div><div dir="auto"><br></div><div dir="auto">With great regards </div><div dir="auto">RedIODev </div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Feb 22, 2026, 23:04 Remi Forax <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[This is my answer, not an official answer]<br>
<br>
Hello,<br>
<br>
TLDR;<br>
Java is fundamentally about being able to compose libraries freely,<br>
and you are proposing to add a new way to do function coloring [1], so No !<br>
<br>
---<br>
<br>
There is a deep irony in this proposal:<br>
<br>
- you want a JDK standard Either because the current ecosystem is fractured.<br>
  Multiple libraries use their own custom Either types, making them impossible to compose.<br>
<br>
- the reality is that by adding Either to the JDK, you don't solve fragmentation, you evolve it.<br>
  It will create a permanent schism between the Exception-based world and the Either-based world.<br>
  So more incompatible libraries.<br>
<br>
Either is also an invitation to Function Coloring.<br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
regards,<br>
Rémi<br>
<br>
[1] <a href="https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/" rel="noreferrer noreferrer" target="_blank">https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/</a><br>
<br>
<br>
----- Original Message -----<br>
> From: "mfejzer" <<a href="mailto:mfejzer@mat.umk.pl" target="_blank" rel="noreferrer">mfejzer@mat.umk.pl</a>><br>
> To: "amber-dev" <<a href="mailto:amber-dev@openjdk.org" target="_blank" rel="noreferrer">amber-dev@openjdk.org</a>><br>
> Sent: Sunday, February 22, 2026 9:45:05 PM<br>
> Subject: Question about introduction of Either/Result like type to the Java language<br>
<br>
> Hello,<br>
> <br>
> I’d like to ask what you think about the introduction of an<br>
> Either/Result-like type like type to the Java language?<br>
> <br>
> Some attempts to write functional-like code in Java encounter no<br>
> standard implementation of Either/Result-like type. Such type is usually<br>
> used for explicit failure handling without exception usage, and is<br>
> present in some other languages. Lack of such type in Java causes<br>
> creation of many ad-hoc implementations which behave slightly<br>
> differently.<br>
> Examples:<br>
> *<br>
> <a href="https://github.com/vavr-io/vavr/blob/main/vavr/src/main/java/io/vavr/control/Either.java" rel="noreferrer noreferrer" target="_blank">https://github.com/vavr-io/vavr/blob/main/vavr/src/main/java/io/vavr/control/Either.java</a><br>
> *<br>
> <a href="https://github.com/functionaljava/functionaljava/blob/series/5.x/core/src/main/java/fj/data/Either.java" rel="noreferrer noreferrer" target="_blank">https://github.com/functionaljava/functionaljava/blob/series/5.x/core/src/main/java/fj/data/Either.java</a><br>
> *<br>
> <a href="https://github.com/aol/cyclops/blob/master/cyclops/src/main/java/cyclops/control/Either.java" rel="noreferrer noreferrer" target="_blank">https://github.com/aol/cyclops/blob/master/cyclops/src/main/java/cyclops/control/Either.java</a><br>
> *<br>
> <a href="https://github.com/resilience4j/resilience4j/blob/master/resilience4j-core/src/main/java/io/github/resilience4j/core/functions/Either.java" rel="noreferrer noreferrer" target="_blank">https://github.com/resilience4j/resilience4j/blob/master/resilience4j-core/src/main/java/io/github/resilience4j/core/functions/Either.java</a><br>
> *<br>
> <a href="https://github.com/kusoroadeolu/ferrous/blob/main/src/main/java/io/github/kusoroadeolu/ferrous/result/Result.java" rel="noreferrer noreferrer" target="_blank">https://github.com/kusoroadeolu/ferrous/blob/main/src/main/java/io/github/kusoroadeolu/ferrous/result/Result.java</a><br>
> Introducing this type to the Java language would provide a standard<br>
> implementation, allowing its use without depending on third-party<br>
> libraries.<br>
> <br>
> Sketch, based on example from ferrous library:<br>
> - java.util.Result<F,S>, sealed interface permitting Success and Failure<br>
> records,<br>
> - records: Success<F,S>(S successValue), Failure<F,S>(F failureValue),<br>
> - available methods: success/failure factories;<br>
> map/flatMap/mapFailure/flatMapFailure; fold; peek/peekFailure;<br>
> consume/ConsumeFailure etc.<br>
> <br>
> Non-goals:<br>
> - Replacing exceptions<br>
> - Extending language syntax<br>
> - Introducing additional functional programming concepts (Monads, Optics<br>
> etc)<br>
> <br>
> Kind regards,<br>
> Mikołaj Fejzer<br>
</blockquote></div>