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

Tue Feb 24 00:41:00 UTC 2026

>
> taking this step effectively forks the world of Java libraries --
> including the JDK itself -- into "old vs new"

I am not really sure if the original post was inspired by Nicolais' video
on exceptions on Java channel, but in it, he suggests something like
boxing-unboxing syntax for Either/Exceptions split. Effectively, this would
allow for seamless switch between worlds and styles  wherever the one
needs, so while style wars point is undoubtable, the "it would be a schism"
alarm seems overfetched to me.

And even if it would be, there were already crises like this, like Reactive
vs Servlet for web world, and JDK didn't hesitate to take a side here with
virtual thread, throwing more uel into ongoing debate.

this is a Big Commitment and should be treated as such, and prioritized
> against other potential BCs.

Cant argue with this though, seamless Either would require many peripheral
upgrades to the language

On Mon, Feb 23, 2026 at 8:17 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> I think the "coloring" analogy may have been a bit strained, but Remi's
> point is clear enough, and well-taken: taking this step effectively forks
> the world of Java libraries -- including the JDK itself -- into "old vs
> new".  Just play out what happens next: the endless style wars, the push to
> rewrite all the "old style" code into "new style", etc.  (Obviously some of
> its proponents want exactly that.)
>
> It's not that adding an Either type is intrinsically unreasonable, but all
> the pro-Either voices are underestimating the cost and impact by orders of
> magnitude.  This is not a "Why don't you 'just' add an Either type, what's
> the harm?", this is a Big Commitment and should be treated as such, and
> prioritized against other potential BCs.
>
>
>
>
>
> On 2/23/2026 3:50 AM, Aaryn Tonita wrote:
>
> The coloring problem is that with async/await syntax a non async function cannot directly call (await) an async function (one must access an event loop, create a new task then block). An Either/Result is just an ordinary java type, so there is no barrier to call such a function and no coloring here, but you seem to have a more general complaint.
>
> There are already two (sort of, same monadic shape but with differing semantics) such implementations in the java standard library, Future and CompletableFuture. Yet asynchronous I/O libraries often implement their own due to deficiencies in these implementations. You get callback hell with such an API (not the coloring problem) if people do not carefully factor synchronous pure functions from the processing code which fetches data with I/O. No coloring problem stops or forces this, just ordinary design difficulties, the coloring problem forces viral contagion of the async functions or extremely careful factoring. Thinking about what would be necessary for the best factoring of either sort of I/O code leads to virtual threads (as I understand it) but doesn't help with general fallible code (due to the differing semantics of Result vs Future).
>
> To be fair, people often conflate the callback hell of a Future/Promise API with the coloring problem of async/await syntax as they are two solutions to the same problem. A marked idiomatic code distinction exists between Result returning APIs and exception handling APIs in their handling of error branching (callback vs effect system), I believe this is what you are objecting to Remi? The encouragement of code that would tend to callback hell and its marked difference with respect to "ordinary" exception handling?
>
> When implementing or refactoring the very same potential functionality one person might say, "I want the same catch block to simply handle all IOException's," and another person might say of the same, "I don't want a single catch block to implicitly handle all IOException's." Or, "I don't want to remember the distinction between map and flatMap,", vs "I want to have a distinguished flatMap so I can choose to join errors or not for a single error handling or distinguished handling." Some of the best ways to avoid callback hell will also come if/when we can pattern match on Result/Optional (not on Future). Although truly the best comes with an early return/try operator (? in rust). This stylistic bifurcation already exists and I don't think having a standard answer for Result would necessarily increase the number of people reaching for that solution.
>
> Like Mikołaj, I also dislike the need to pull in a library just to get Either/Result, and certainly often feel the need (with streams or when designing a callback api and needing to make the same call or not as the stream api with respect to exceptions on the callback). Another reason I brought up CompletableFuture is to indicate that it would probably need some level of love to actually provide a good API that people wouldn't seek to reimplement. Its semantics with respect to null would probably be contentious although maybe we are approaching the end of that with null restricted types. The lack of a standard Result definitely feels like a hole, especially with respect to streams. Encountering that hole and working around it is practically a rite of passage now! That rite of passage leads some people to desire a complete lack of checked exceptions (and use of sneaky throws), some people to reach for Result, other people to refactor to imperative iteration, and so on. Even if you aren't in that camp, it would be nice if the people in the Result camp could have a standard batteries-included implementation just so you would have a standard path back to your own camp (and hopefully a smaller dependency footprint).
>
>
>
>
> On Sunday, February 22nd, 2026 at 11:05 PM, Remi Forax <forax at univ-mlv.fr> <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> <mfejzer at mat.umk.pl>
> To: "amber-dev" <amber-dev at openjdk.org> <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/20260224/0573c404/attachment-0001.htm>