<!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;">
No, the proposal was not inspired by https: //www. youtube. com/watch?v=99s7ozvJGLk but the video is interesting. In Nicolais' video Either is used with exceptions on left side. Typical Either usage is usually with types for values, so left side</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!N72wPInu0EKElLDAnZOUe-Cx-J-yIWT2ohKUUmnQEozmFPPbJxSsCOpq4r18_T34N0LWpGAdTV-EfG697mz1xbH6v1YZ14Eg$" 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="pfptBannersmtaqq4" 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="pfptBannersmtaqq4" style="all: unset !important; float:left !important; display:block !important; margin: 1px 0 1px 0 !important; max-width: 600px !important;">
<div id="pfptBannersmtaqq4" 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="pfptBannersmtaqq4" 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="pfptBannersmtaqq4" 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="pfptBannersmtaqq4" href="https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ACWV5N9M2RV99hQ!N72wPInu0EKElLDAnZOUe-Cx-J-yIWT2ohKUUmnQEozmFPPbJxSsCOpq4r18_T34N0LWpGAdTV-EfG697mz1xbH6v1YZ14Eg$"
style="all: unset !important; display: inline-block !important; text-decoration: none">
<div class="pfptPrimaryButtonsmtaqq4" 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>
#pfptBannersmtaqq4 { all: revert !important; display: block !important;
visibility: visible !important; opacity: 1 !important;
background-color: #60beeb !important;
max-width: none !important; max-height: none !important }
.pfptPrimaryButtonsmtaqq4:hover, .pfptPrimaryButtonsmtaqq4:focus {
background-color: #77a8c4 !important; }
.pfptPrimaryButtonsmtaqq4: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">No, the proposal was not inspired by
https://www.youtube.com/watch?v=99s7ozvJGLk but the video is
interesting.
In Nicolais' video Either is used with exceptions on left side.
Typical Either usage is usually with types for values, so left side has
some type for value, which does not need to be an exception.
Thus, common Either usage avoids requirement about some exception
hierarchy, as types on left or right side do not need to extend some
super type, as long as you can map one to other, or extract values from
Either in the end.
For the arguments about split/schism there is already Optional and
Stream, which work on values, not exceptions.
Similarly, Optional and Stream introduced the same kind of function
coloring as Either has.
Moreover, any type which has defined "flatMap" has function coloring, as
this type of operation moves function from one color to the other.
Kind regards,
Mikołaj Fejzer
On 2026-02-24 01:41, Olexandr Rotan wrote:
>> 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@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@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>