<head><!-- BaNnErBlUrFlE-HeAdEr-start -->
<style>
#pfptBannerwfhrnk1 { all: revert !important; display: block !important;
visibility: visible !important; opacity: 1 !important;
background-color: #60beeb !important;
max-width: none !important; max-height: none !important }
.pfptPrimaryButtonwfhrnk1:hover, .pfptPrimaryButtonwfhrnk1:focus {
background-color: #77a8c4 !important; }
.pfptPrimaryButtonwfhrnk1: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><!-- 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;">
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,</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 External Sender
</td></tr>
<tr><td style="color:#000000; font-weight:normal; font-family: 'Arial', sans-serif; font-size:12px; direction: ltr">
This message came from outside your organization.
</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!Op20OCaOcCQGmHzvfxPZ9sJjvXFDXLgGnT8Bwco9vIk5V0BKGICH3ESYIyN4xsa7O4wyQIrW-L3yQtpV_NOH3lEkLEAIaq2Ws2_kzyCSMtpE2dyqfmIeOFVRQw267pA$" 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="pfptBannerwfhrnk1" 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="pfptBannerwfhrnk1" style="all: unset !important; float:left !important; display:block !important; margin: 1px 0 1px 0 !important; max-width: 600px !important;">
<div id="pfptBannerwfhrnk1" 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 External Sender
</div>
<div id="pfptBannerwfhrnk1" 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;">
This message came from outside your organization.
</div>
</div>
<div id="pfptBannerwfhrnk1" 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="pfptBannerwfhrnk1" href="https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ACWV5N9M2RV99hQ!Op20OCaOcCQGmHzvfxPZ9sJjvXFDXLgGnT8Bwco9vIk5V0BKGICH3ESYIyN4xsa7O4wyQIrW-L3yQtpV_NOH3lEkLEAIaq2Ws2_kzyCSMtpE2dyqfmIeOFVRQw267pA$"
style="all: unset !important; display: inline-block !important; text-decoration: none">
<div class="pfptPrimaryButtonwfhrnk1" 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 -->
<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:monospace;font-size:large">taking this step effectively forks the world of Java libraries -- including the JDK itself -- into "old vs new"</span></blockquote><div>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.<br><br>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.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:monospace;font-size:large">this is a Big Commitment and should be treated as such, and prioritized against other potential BCs.</span></blockquote><div>Cant argue with this though, seamless Either would require many peripheral upgrades to the language</div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Feb 23, 2026 at 8:17 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<font size="4" face="monospace">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.)<br>
<br>
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. <br>
<br>
<br>
<br>
<br>
</font><br>
<div>On 2/23/2026 3:50 AM, Aaryn Tonita
wrote:<br>
</div>
<blockquote type="cite">
<pre>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 <a href="mailto:forax@univ-mlv.fr" target="_blank"><forax@univ-mlv.fr></a> wrote:
</pre>
<blockquote type="cite">
<pre>[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] <a href="https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/" target="_blank">https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/</a>
----- Original Message -----
</pre>
<blockquote type="cite">
<pre>From: "mfejzer" <a href="mailto:mfejzer@mat.umk.pl" target="_blank"><mfejzer@mat.umk.pl></a>
To: "amber-dev" <a href="mailto:amber-dev@openjdk.org" target="_blank"><amber-dev@openjdk.org></a>
Sent: Sunday, February 22, 2026 9:45:05 PM
Subject: Question about introduction of Either/Result like type to the Java language
</pre>
</blockquote>
<pre></pre>
<blockquote type="cite">
<pre>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:
*
<a href="https://github.com/vavr-io/vavr/blob/main/vavr/src/main/java/io/vavr/control/Either.java" target="_blank">https://github.com/vavr-io/vavr/blob/main/vavr/src/main/java/io/vavr/control/Either.java</a>
*
<a href="https://github.com/functionaljava/functionaljava/blob/series/5.x/core/src/main/java/fj/data/Either.java" target="_blank">https://github.com/functionaljava/functionaljava/blob/series/5.x/core/src/main/java/fj/data/Either.java</a>
*
<a href="https://github.com/aol/cyclops/blob/master/cyclops/src/main/java/cyclops/control/Either.java" target="_blank">https://github.com/aol/cyclops/blob/master/cyclops/src/main/java/cyclops/control/Either.java</a>
*
<a href="https://github.com/resilience4j/resilience4j/blob/master/resilience4j-core/src/main/java/io/github/resilience4j/core/functions/Either.java" target="_blank">https://github.com/resilience4j/resilience4j/blob/master/resilience4j-core/src/main/java/io/github/resilience4j/core/functions/Either.java</a>
*
<a href="https://github.com/kusoroadeolu/ferrous/blob/main/src/main/java/io/github/kusoroadeolu/ferrous/result/Result.java" target="_blank">https://github.com/kusoroadeolu/ferrous/blob/main/src/main/java/io/github/kusoroadeolu/ferrous/result/Result.java</a>
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>
</blockquote>
<pre></pre>
</blockquote>
</blockquote>
<br>
</div>
</blockquote></div>