I agree with you—I prefer explicit synchronization. But this isn't an accidental flaw in Java's design, it's the entire purpose of their chosen model. A lot of people dislike the fact that async/await causes function coloring [0] and as a result may lead to duplication of sync and async version of functions. These people see Java as dodging a bullet and learning from past mistakes in other languages, so it's unlikely that Java will have anything comparable to async/await.
Yep, I agree. I tend to be a type system maximalist: I'd rather have everything that is possible to encode statically be encoded statically, even if it leads to less flexibility later.
If you're starting a new Java codebase from scratch, you can create the structure where the language doesn't using classes, but it'd be nice to have syntactic support for it.
Very simple - in Java, almost any IO operation in blocking. Exceptions are the stuff in the NIO package, thread interruption and signalling, and maybe process termination.
Well, JS is paired with a single-threaded execution model, so you only have concurrency to worry about. C#, Java has proper multithreading as well, that gives another dimension to the problem.
Then you don’t start it in a virtual thread. Your calls automatically become blocking or not blocking depending on your callsites, which is the proper place to decide that.
Lombok is unfortunately a separate programming language, albeit insufficiently distinct from Java.
(Why? Because it uses internal compiler APIs to change the behaviour of code you write in ways that are not valid: annotation processors are supposed to generate new classes, not mutate existing classes.)
[0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...