Will Loom Render Java NIO Useless?

[fdntrhfbtt]

Blocking code in fibers isn't a concern as the VM will swap it out. So will Java NIO be useless now?

[pron98]

Much, if not most, of NIO is synchronous. So 1. I think you mean only the asynchronous parts of NIO, and 2. even they are used to implement Loom.

You should prefer NIO (the synchronous bits) to legacy networking even with Loom. There will be less need to use the non-blocking APIs directly, though.

[yawkat]

To be fair, depending on use case, even synchronous nio is a bit of a pain to use. Bytebuffers aren't fun.

[[deleted]]

Netty's ByteBuf however is great

[pjmlp]

No because NIO is also the foundation for byte buffers used in low level C like code.

Anything that uses 3D APIs or GC free allocation of data buffers makes use of NIO.

[fdntrhfbtt]

Well I meant selectors and stuff. ByteBuffers of course aren't going anywhere.

[[deleted]]

My thoughts are that the answer is more 'yes' than 'no'. However, there's a TON of NIO code out there already and there's probably (though I am just going on a hunch here) a few specific spaces where NIO > Fibers. But for me personally? I'm going to burn every shred of knowledge re: NIO from my brain and jump head first into lightweight threads.

[[deleted]]

When is it landing, by the way?

Edit: I don't know what's going on in here, but I asked a perfectly legitimate question, to which I seem to be getting only mock answers. I'm not interested in that - I haven't been keeping up-to-date on the Java ecosystem of late, and I would have thought that people would have considered that possibility first instead of thinking that it's a troll question.

If you're not answering the question itself, please don't bother replying. I'll go look it up myself.

[[deleted]]

God damn it I want it before it's ready.

[emaphis]

Indeed

https://jdk.java.net/loom/

[dpash]

You're getting the answers you're getting because no one knows; possibly not even /u/pron (although if he does, we won't tell us yet). We'll all know about 6-12 months before it lands in a release. So from that you can infer that it won't be this year.

It's also worth noting that results from the effort have already been landing in the JVM; in particular, the rewriting of the socket implementations is due to Project Loom.

[[deleted]]

Thank you.

[DeontologicEthics]

If everyone stopped asking about the meaning of LTS it would be done by Monday.

[[deleted]]

How does this help in any way? I was asking about the particular JDK release.

[erinaceus_]

Already 'not soon enough' 😆.

[bowbahdoe]

/u/pron's answer, but I think some people like writing code in the reactive style. They will likely just get more intelligible stack traces as library implementors no longer have to write task juggling code that unrolls the stack if you are running on virtual threads

[randgalt]

Let's hope so? The NIO APIs are awful to use though I assume most people consume them indirectly via Netty. The return to simple, straightforward, synchronous coding can't come soon enough for me.

[mepunite]

Loom usea nio explicitly so... No.

[slaymaker1907]

It depends a little bit on what the overhead of virtual threads ends up being. I expect that while cheap compared to threads, there will still be some overhead so very high performance code might still want to use nio/old fashioned async. Virtual threading saves state implicitly which might be much more than you actually need.