Ugly nested parameterizations

Note. I'm not sure if it's a better fit for Software Recommendations, but I'll give it a try. Suppose there's a long IO operation that may result in some return value — but doesn't have to. Completion with no return value is different from the operation being pending. Do I have better options other than returning CompletableFuture from my asynchronous method? It's a bit of a mouthful, especially if MyType is generic itself. If I need to return a list of some entities, it can get as ugly as CompletableFuture (remeber, an empty list is different from no list, I can't skip the Optional layer). In my case it's a bit different, though, Optional. A cache class may have a list of entities that you may fetch by a key, but you may also need to wait for the loading to finish. Thus, cacheable, cached, not cacheable are three distinct states. Java 8.

Feb 25, 2025 - 14:35

Note. I'm not sure if it's a better fit for Software Recommendations, but I'll give it a try.

Suppose there's a long IO operation that may result in some return value — but doesn't have to. Completion with no return value is different from the operation being pending.

Do I have better options other than returning CompletableFuture> from my asynchronous method? It's a bit of a mouthful, especially if MyType is generic itself. If I need to return a list of some entities, it can get as ugly as CompletableFuture>>> (remeber, an empty list is different from no list, I can't skip the Optional layer).

In my case it's a bit different, though, Optional>>>. A cache class may have a list of entities that you may fetch by a key, but you may also need to wait for the loading to finish. Thus, cacheable, cached, not cacheable are three distinct states.

Java 8.