KEEP VS jspecify

Nice. So for example, it looks like Kotlin has a nearly identical feature at the language level which will be optimizable when Valhalla ships: https://github.com/Kotlin/KEEP/blob/master/notes/value-class...

> In the future, in a Valhalla-capable JVM, JVM primitive classes will enable efficient representation of Kotlin value classes with an arbitrary number of underlying fields on JVM.

Most other languages agree that checked exceptions are not good by not having them.

As for alternatives, Try/Result and similar monads have decent adoption even in Java, but personally I quite like the Kotlin philosophy [1] to not have generic error containers and either use runtime exceptions or make failures of the return type.

[1] https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/...

If you want to read more and don't want to google it: https://github.com/Kotlin/KEEP/blob/data-objects/proposals/data-objects.md

Under the hood: https://github.com/Kotlin/KEEP/blob/master/proposals/coroutines.md .

you can check more here

You can use explicit API mode, then everything needs explicit visibility

There's also a fair amount of content to explore starting at jspecify.org.

With some projects like https://github.com/jspecify/jspecify you can say your code is @NullMarked, meaning all nullable fields are explicitly marked with @Nullable. That being ubiquitous is...some point in the future.

Issue about Void

Details are being worked out in JSpecify [issue 79](https://github.com/jspecify/jspecify/issues/79). At present it is thought that we can have a 1.0 without it; that could still change. Please feel free to join the conversation.

Coincidentally that's my current project -- sort of. We need to stay with an annotation-based approach for a bit longer but we think there's a path. http://jspecify.org

Well, within a @NullMarked context you already don't have to annotate non-nullable types. You probably want a warning when someone forms a @Nullable type from that class, and I've just filed #228 about that.