WebStorm is indeed amazing. It takes separate stack traces and glues them together which means it needs to keep old stack traces in memory then constantly compare the objects passed along to figure out which stack to glue where.
As I said, it's problematic for production. So in the IDE you can indeed see the glued stack but in the browser... Or on the server...
Then there's the context. Since glued stack traces could be in-theory separate threads (at least in Java async calls) you might get weird behaviors where values of objects across the stack can be wildly different.
And no. You don't have a separate thread doing the IO. That's exactly the idea Loom is solving. Javas traditional stream IO is thread based. But we have a faster underlying implementation in NIO which uses the native select calls. The idea here is that a thread receives a callback when the connection has data waiting and can wait for data. This means the system can wake up the thread as needed, very efficiently. So there's no additional thread.
Yes I think I got that. I was not saying that Java creates a new thread for every IO operation but that async/await in JavaScript etc. must do something like starting a new "pseudo-thread". And that is why debugging in Java is easier - because it doesn't need to start a new thread. That's what I was trying to understand. Thanks.
As I said, it's problematic for production. So in the IDE you can indeed see the glued stack but in the browser... Or on the server...
Then there's the context. Since glued stack traces could be in-theory separate threads (at least in Java async calls) you might get weird behaviors where values of objects across the stack can be wildly different.
And no. You don't have a separate thread doing the IO. That's exactly the idea Loom is solving. Javas traditional stream IO is thread based. But we have a faster underlying implementation in NIO which uses the native select calls. The idea here is that a thread receives a callback when the connection has data waiting and can wait for data. This means the system can wake up the thread as needed, very efficiently. So there's no additional thread.