<!DOCTYPE html>
<!-- BaNnErBlUrFlE-BoDy-start -->
<!-- Preheader Text : BEGIN -->
<div style="display:none !important;display:none;visibility:hidden;mso-hide:all;font-size:1px;color:#ffffff;line-height:1px;max-height:0px;opacity:0;overflow:hidden;">
Based on my understanding both Optional and Stream have the similar properties regarding function coloring as Either, while having different properties than async/await constructs from other languages. For example methods with signatures like: </div>
<!-- Preheader Text : END -->
<!-- Email Banner : BEGIN -->
<div style="display:none !important;display:none;visibility:hidden;mso-hide:all;font-size:1px;color:#ffffff;line-height:1px;max-height:0px;opacity:0;overflow:hidden;">ZjQcmQRYFpfptBannerStart</div>
<!--[if ((ie)|(mso))]>
<table border="0" cellspacing="0" cellpadding="0" width="100%" style="padding: 0px 0px 10px 0px; direction: ltr" lang="en"><tr><td>
<table border="0" cellspacing="0" cellpadding="0" style="padding: 0px 8px 6px 8px; width: 100%; border-radius:4px; border-top:4px solid #8193a0;background-color:#60beeb;"><tr><td valign="top">
<table align="left" border="0" cellspacing="0" cellpadding="0" style="padding: 0px 8px 4px 8px; font-size: 12px; line-height: 16px">
<tr><td style="color:#000000; font-family: 'Arial', sans-serif; font-weight:bold; font-size:14px; line-height: 20px; direction: ltr">
This Message Is From an Untrusted Sender
</td></tr>
<tr><td style="color:#000000; font-weight:normal; font-family: 'Arial', sans-serif; font-size:12px; direction: ltr">
You have not previously corresponded with this sender.
</td></tr>
</table>
<![if ie]><br clear="all"><![endif]>
<table align="right" border="0" cellspacing="0" cellpadding="0" style="padding: 0px 0px 4px 0px; font-size: 14px; line-height: 36px"><tr>
<td style="direction: ltr"> <a target="_blank" href="https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ACWV5N9M2RV99hQ!N72wnMkP-khu39pqt7KUOikZV-FQPUipMvt7uS84lS1OaApG5o8PvmkwkbcSjtUxvdxmiWupdWxeSABVkr1OXzNv7YPYTGF8$" style="mso-padding-alt: 7px; padding: 7px; border-radius: 2px; border: 1px solid #666666; "><strong style="font-weight: normal; color: #000000; text-decoration: none; font-family: 'Arial', sans-serif; font-size: 14px;"> Report Suspicious </strong></a> </td>
</tr></table>
</td></tr></table>
</td></tr></table>
<![endif]-->
<![if !((ie)|(mso))]>
<div dir="ltr" lang="en" id="pfptBanneruj38k3h" style="all: revert !important; display:block !important; text-align: left !important; margin: 0 0 10px 0 !important; padding:7px 16px 8px 16px !important; border-radius: 4px !important; min-width: 200px !important; background-color: #60beeb !important; background-color: #60beeb; border-top: 4px solid #8193a0 !important; border-top: 4px solid #8193a0;">
<div id="pfptBanneruj38k3h" style="all: unset !important; float:left !important; display:block !important; margin: 1px 0 1px 0 !important; max-width: 600px !important;">
<div id="pfptBanneruj38k3h" style="all: unset !important; display:block !important; visibility: visible !important; background-color: #60beeb !important; color:#000000 !important; color:#000000; font-family: 'Arial', sans-serif !important; font-family: 'Arial', sans-serif; font-weight:bold !important; font-weight:bold; font-size:14px !important; line-height:1.29 !important; line-height:1.29">
This Message Is From an Untrusted Sender
</div>
<div id="pfptBanneruj38k3h" style="all: unset !important; display:block !important; visibility: visible !important; background-color: #60beeb !important; color:#000000 !important; color:#000000; font-weight:normal; font-family: 'Arial', sans-serif !important; font-family: 'Arial', sans-serif; font-size:12px !important; line-height:1.5 !important; line-height:1.5; margin-top:2px !important;">
You have not previously corresponded with this sender.
</div>
</div>
<div id="pfptBanneruj38k3h" style="all: unset !important; float: right !important; display: block !important; display: block; margin-left: 16px !important; margin-top: 1px !important; text-align: right !important; width: fit-content !important; font-size: 12px !important">
<a id="pfptBanneruj38k3h" href="https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ACWV5N9M2RV99hQ!N72wnMkP-khu39pqt7KUOikZV-FQPUipMvt7uS84lS1OaApG5o8PvmkwkbcSjtUxvdxmiWupdWxeSABVkr1OXzNv7YPYTGF8$"
style="all: unset !important; display: inline-block !important; text-decoration: none">
<div class="pfptPrimaryButtonuj38k3h" style="display: inline-block !important; display: inline-block; visibility: visible !important; opacity: 1 !important; color: #000000 !important; color: #000000; font-family: 'Arial', sans-serif !important; font-family: 'Arial', sans-serif; font-size: 14px !important; font-weight: normal !important; text-decoration: none !important; border-radius: 2px !important; margin-top: 3px !important; margin-bottom: 3px !important; margin-left: 16px !important; padding: 7.5px 16px !important; white-space: nowrap !important; width: fit-content !important;
border: 1px solid #666666">
Report Suspicious
</div>
</a>
</div>
<div style="clear: both !important; display: block !important; visibility: hidden !important; line-height: 0 !important; font-size: 0.01px !important; height: 0px"> </div>
</div>
<![endif]>
<div style="display:none !important;display:none;visibility:hidden;mso-hide:all;font-size:1px;color:#ffffff;line-height:1px;max-height:0px;opacity:0;overflow:hidden;">ZjQcmQRYFpfptBannerEnd</div>
<!-- Email Banner : END -->
<!-- BaNnErBlUrFlE-BoDy-end -->
<html>
<head><!-- BaNnErBlUrFlE-HeAdEr-start -->
<style>
#pfptBanneruj38k3h { all: revert !important; display: block !important;
visibility: visible !important; opacity: 1 !important;
background-color: #60beeb !important;
max-width: none !important; max-height: none !important }
.pfptPrimaryButtonuj38k3h:hover, .pfptPrimaryButtonuj38k3h:focus {
background-color: #77a8c4 !important; }
.pfptPrimaryButtonuj38k3h:active {
background-color: #8193a0 !important; }
html:root, html:root>body { all: revert !important; display: block !important;
visibility: visible !important; opacity: 1 !important; }
</style>
<!-- BaNnErBlUrFlE-HeAdEr-end -->
</head><body><pre style="font-family: sans-serif; font-size: 100%; white-space: pre-wrap; word-wrap: break-word">Based on my understanding both Optional and Stream have the similar
properties regarding function coloring as Either, while having different
properties than async/await constructs from other languages.
For example methods with signatures like:
String doSomething(String parameter) //color blue
Optional<String> doSomethingStrange(String parameter) //color red
have different colors, but Optional related colors here can be easily
changed via "getOrElse" (red -> blue) or "of" (blue -> red).
Thus if Optional or Stream are allowed, why not Either?
Kind regards,
Mikołaj Fejzer
On 2026-02-23 09:50, 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@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@mat.umk.pl>
> To: "amber-dev" <amber-dev@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
</pre></body></html>