Java itself doesn't have many APIs with callbacks. all I/O and locks APIs, for example, looks synchronous. The problem is that since Java 8, lambdas and streams got abused (even in my examples, to quickly create functions). Also most of the "network framework" out there are still not leveraging virtual threads, since it's a major redesign to move away from the all the callback hell created to workaround async I/O limitations. But now the language allows to write cleaner code, so it's just a matter of choosing a newer/better set of libraries.
@@th30z-code You still can't, for example, write sequential-looking code that sends an HTTP request without blocking the UI thread. This was a problem in every language a while ago, and many fixed it by switching to an async/await model. Java refused to do anything about it, so to this day, you still have to write uglier, unmaintainable code riddled with callback lambdas to keep your app's UI responsive.
can you share a bit more? I haven't used any java UI framework lately, but my guess is that is just a "UI framework problem", meaning that the framework is still not leveraging virtual threads. If your "onClick()" for examples is run in a virtual thread you can use the HttpClient.sendSync() client, take locks and do other blocking stuff with a code that will look sequential and not blocking the UI.
@@th30z-code It's not a framework/library problem, it's a problem with the language itself. It doesn't matter what framework you're using, you simply cannot write sequencial, yet asynchronous code in Java until Oracle decides to implement some sort of async/await feature onto the language itself; until then, Java remains a terrible language to write asynchronous code in.
virtual threads are the async/await alternative. In the way they implemented there is no reason to add new keywords like async/await. java takes care of scheduling the threads by itself, since underneath is known which operations are "blocking I/O" and which are not. so you can think as it as "java adds the await where it is needed". so, if your code/framework uses virtual threads you now can write sequential code and it will be the same as using async/await in other languages. just try to write a simple example with a Thread.sleep() or an httpClient.send(), you'll see that it will actually look nice even without the async/await keyword.
