Either way it feels like optionals are going to be deprecated real quick now we have sealed interfaces and record matching. They let you get rid of so much of the unpleasantness in dealing with this API. Instead you can

    public sealed interface Maybe<T> {

        <T2> Maybe<T2> map(Function<T, T2> mapper);
        <T2> Maybe<T2> flatMap(Function<T, Maybe<T2>> mapper);
        T elseGet(T fallback);

        record Just<T>(T value) implements Maybe<T> {
            public <T2> Maybe<T2> map(Function<T, T2> mapper) {
                return new Just<T2>(mapper.apply(value));
            }
            public <T2> Maybe<T2> flatMap(Function<T, Maybe<T2>> mapper) {
                return mapper.apply(value);
            }
            public T elseGet(T fallback) {
                return value;
            }
        }

        record Empty<T>() implements Maybe<T> {
            public <T2> Maybe<T2>  map(Function<T, T2> mapper) {
                return new Empty<>();
            }
            public <T2> Maybe<T2>  flatMap(Function<T, Maybe<T2>> mapper) {
                return new Empty<>();
            }
            public T elseGet(T fallback) {
                return fallback;
            }
        }

    }

    public void demo() {
        Maybe<String> foo = new Maybe.Empty<String>();

        System.out.println(
            switch (foo) {
                case Maybe.Just(String val) -> "Hello " + val;
                case Maybe.Empty() -> "Fine, leave me hanging";
            }
        );

    };

> Yes, some aspects require fixing (e.g. the interaction of lambdas with checked exceptions; there's much we can do there, but we need to design this carefully)

I do like the Java platform in general, but this sort of argument from hypothetical future Java fixes strikes my as incredibly disingenuous. People aren't programming in a hypothetical future Java.

I can literally pose no argument against your imagined solution to this problem without very specific details. (Implication being, it's a straw man at best.)

And saying saying stuff like (in an adjacent thread):

> You're assuming that deconstructing and exhaustive patterns will continue to be restricted to ADTs only. That may or may not be the case.

Is just complete fiction. (EDIT: Are you going to solve the halting problem, or are you going to provide details before just promising "it'll be ok"? I assume the Halting Problem is out of the question, but what's the plan, then? Details, pls)

Either point to extant JEPs or explain in detail what the exact plan is, please.

The latest Mockito works with Java 21; you'll just see a warning about the usage of the bytebuddy agent. In the future, you'll need to explicitly approve the loading of agents (you can call it "magic"), which will improve the security of your programs.

Since Java 9, new features are finally coming again. However, the ecosystem had gotten reliant on certain JDK internals being accessible and stable, while in fact they were neither. That will require some more years to properly transition over.

The only feature that really got obsoleted is the Security Manager and the underscore variable name. Primitive wrapper class constructors are on the chopping block next. Most other things are merely being restricted to harden the platform, with ample time to prepare.

Edit: LTS hopping is probably an unwise strategy as one will harvest only disadvantages: few updates, no performance improvements, no new features, and complicated migrations when it is time to upgrade. One best upgrades as soon as the new version becomes available (as people did before Java 8) or stays on LTS until the software is retired.

> Unfortunately, since Java 9 the rate of change seems to have increased a lot.

Since Java 9, they don't introduce changes, they introduce new features which is a bit different.

IT is a field that (should) attract people that are for fast paced environments, not old school slow-to-innovate industries.

But Java is a mainstream language, and so we generally try to adopt features that a large majority of programmers are ready for, which means, pretty much by definition, that we adopts things later than most languages. Just to give you an example, we only recently added algebraic data types, but in some ways we still added them too early because far too many programmers don't yet know how to work with ADTs, but we felt we had to add them because we thought they're the best way to work with simple data in a language like Java, especially since we didn't want to add property or Kotlin-like data classes, as we think these are bad features. This emphasises another point, and that is that we're not "catching up". Most features don't prove their worth and will never find their way to Java, because we try to pick the minimal set of features that will give the most bang, and that reduces the growth of language complexity, which can truly harm adoption. In this way we also managed to avoid async/await.

Another example that people often ask about is named and default parameters. It looks like lots of languages have them, but the problem is that it's usually implemented in a way that harms those languages. For example, C#, Kotlin, and Swift all generally try to support separate compilation and binary compatibility, but their named & default parameters break that. We'll only add the feature to Java once we know how to do it right (something that I think no other language that cares about separate compilation has done yet), and we have some ideas.

And I disagree that FP features are awkward to use in Java (well, some pure-functional theorems don't work because of null, but they also don't work because of reflection, anyway, and they don't work in most non-pure-FP languages, either).