`then` is definitely less intuitive than `map` considering that you actually want to, well, map to something else.<p>Semantically, `then` would be equivalent to `ifPresent`, but, well, then both are intuitive.
Interesting attempt, however:<p>1. There was no need to implement Set interface to support foreach loop. Iterable would be sufficient. Set is too specific and is not an obvious choice (for return type interoperability in subclasses sometimes it would be more convenient to have List).<p>2. Moving from isPresent/get to try/catch checked exception will produce worse result. Either you wrap ‘get’ immediately and get more verbose code, or you catch somewhere else and loose the context and readability. In “throws Exception” methods absence of stack trace will be painful.<p>3. Renaming ‘map’ to ‘then’ is too late. “Then” was used in functional style libraries more than 15 years ago, Java 8 settled the naming convention and it’s better to follow it.<p>4. What Optional is often missing is the context of empty state. It would be cool to have an implementation of None with a Throwable cause (and orElseThrow throwing it wrapped).
The real improvement is to lift nullability up to the type system. That way, every type acts as an optional by default, and the computer can infer when a nullable type has been null-checked.<p>This is what Kotlin does - it's truly freeing to work with.
> The exception that is raised when an empty Maybe is used is a checked exception so you don't forget to handle it.<p>I think they acknowledged get() should have been getOrThrow() so it's clear what can happen, but I don't know if making it checked is an improvement.<p>> It implements the Collection interface, so it can be accessed with a for-loop.<p>I'm curious what the use cases are for this. I've used Optional, it can be annoying, it's mostly around it being verbose and APIs being inconsistent. It was never wishing I could treat it as a collection.
`map()` makes Optional congruent with java Streams. Optionals are very frequently used with Streams, eg:<p><pre><code> someList.stream().map(Thing::foo).findFirst().map(Other::bar)...
</code></pre>
And checked exceptions are a scourge. There's a reason post-Java languages like C#, Scala, and Kotlin abandoned them. Even lombok offers @SneakyThrows.<p>The Java Optional<?> is pretty good as-is. The main improvement I'm make is that it needs to be Serializable. And woven into the core collection classes.
I really dislike the use of exceptions - particularly checked exceptions - to handle control flow for things like this. I mean, it's not EXCEPTIONAL to have an empty Optional, right? Their use here is an anti-pattern to my eye.<p>Java (the language) should just drop the notion of checked exceptions. It would be fully backward compatible as the checked/unchecked distinction is a language feature not a JVM one.<p>They simply don't work with Stream and cause abstraction leaks everywhere (e.g. you have to handle IOExpection for operations on StringWriter). It obfuscates flow control.<p>Anyway the problem with Optional is not going to be fixed by renaming API methods and fiddling like this (sorry to be harsh). The reason Optional is broken is because there is so much legacy APIs which use null to represent "no result" and until all of these APIs are changed/deprecated, then Optional will never be a very useful tool.<p>As others have commented, the correct solution would be to ditch Optional completely along with the mass of flavors of @Nullable, @NotNull, etc that everyone uses along with having to use package_info.java everywhere and just make "nullability" part of the type system.<p>Kotlin got it right here. But it would be a breaking change in Java to make not-nullable the default. They could do it the opposite way to Kotlin - add a marker for "not-nullable" instead of one for "nullable" - e.g. "String!" would be a not-nullable String instead of say "String?" representing a nullable string.
I would make the abstract class "Maybe" a sealed class with None and Some being the only permitted implementation
So that clients can use pattern matching (enhanced switch)
This seems to be worse in every way to Optional.<p>The throwing of a checked exception is ludicrous. It's a classic case of abusing checked exceptions for flow control. The right approach is an isPresent() or isEmpty() call followed by a get() when you know it's present. Static analysis can ensure you don't screw this up.<p>Similarly, using then and thenMaybe instead of map and flatMap means it now has its own terminology different from Stream.<p>Being able to iterate it is dubious. You can already .stream() an Optional (to an empty or 1-element stream). You can also if (o.isPresent()) { o.get(); } which is hardly burdensome. I'm trying to figure out how a for-each loop is an improvement. But if you must: o.map(Collections::singleton).orElse(Collections.empty()). Or o.stream().toList().<p>I applaud the author for experimenting with different API designs, but this one is just not good. It causes more trouble than it solves.
Checked exception in a Optional.get is really the worst idea that you could possibly come up with.<p>Have a look at vavr (<a href="https://github.com/vavr-io/vavr">https://github.com/vavr-io/vavr</a>)
They did a fantastic job and the DX is so much better than anything java std has to offer. They have immutable equivalents for pretty much any java util data structure as well as either try option etc. To me the one lib that makes java actually feel fresh.
I really hate the inclusion of a "FastException" and "UnsafeUtils" class.<p>Many developers will consistently make the wrong choice thinking their complex (but cold) execution path needs to be extra sleek and fast. But the reckoning comes during debugging (most likely by somebody else) where you have extra levels of indirection and non-expected violations of typically default behavior.