3 ms·

Far fewer applications need this than many are led to believe. That said, this is always a welcome addition although this really doesn't add more than syntax ov

Far fewer applications need this than many are led to believe. That said, this is always a welcome addition although this really doesn't add more than syntax over the stuff we've had in java.nio for a couple of decades

closeparen 5y ago
You can always write a callback oriented program, but this is much nicer!
- abraxas 5y ago
  Yeah agreed. It is definitely very welcome syntax sugar and I'll take it over JS callback hell or async/await stuff any day. I just wanted to point out that non-blocking I/O has been available in Java for a long time so high I/O throughput applications have been possible to build in Java even though it required more mental overhead.
  - nhoughto 5y ago
    More mental overhead and tough ecosystem, you end up in the coloured functions problem where you choose to write non blocking code so now all your dependencies / libraries must too. Nodejs worked because it was like this from day 1 but java isn’t. This change would make the base primitives non blocking (really cheap Blocking which is better) by default, so now you can use any~ library and it should just work. Waaay better.
    - sgift 5y ago
      > Nodejs worked because it was like this from day 1 but java isn’t. And even there "worked" is a very liberal definition. Callbacks, promises and whatever else you can find will imho never be as intuitive as threads.
      - nhoughto 5y ago
        yeah it worked, as in the ecosystem was consistent with a single non-blocking pattern.. and then almost immediately went in 5 different directions around how to program around it.. callback hell, async/await, generators, promises etc..
- xxs 5y ago
  It will still suck compared to NIO & DirectBuffers - and if you really need NIO, this won't be a replacement. Using non-blocking read/write pretty quickly expands to writing your own scheduler with all the needed quirks/boosts/etc.

closeparen 5y ago

You can always write a callback oriented program, but this is much nicer!

abraxas 5y ago
Yeah agreed. It is definitely very welcome syntax sugar and I'll take it over JS callback hell or async/await stuff any day. I just wanted to point out that non-blocking I/O has been available in Java for a long time so high I/O throughput applications have been possible to build in Java even though it required more mental overhead.
- nhoughto 5y ago
  More mental overhead and tough ecosystem, you end up in the coloured functions problem where you choose to write non blocking code so now all your dependencies / libraries must too. Nodejs worked because it was like this from day 1 but java isn’t. This change would make the base primitives non blocking (really cheap Blocking which is better) by default, so now you can use any~ library and it should just work. Waaay better.
  - sgift 5y ago
    > Nodejs worked because it was like this from day 1 but java isn’t. And even there "worked" is a very liberal definition. Callbacks, promises and whatever else you can find will imho never be as intuitive as threads.
    - nhoughto 5y ago
      yeah it worked, as in the ecosystem was consistent with a single non-blocking pattern.. and then almost immediately went in 5 different directions around how to program around it.. callback hell, async/await, generators, promises etc..
xxs 5y ago
It will still suck compared to NIO & DirectBuffers - and if you really need NIO, this won't be a replacement. Using non-blocking read/write pretty quickly expands to writing your own scheduler with all the needed quirks/boosts/etc.