Scanner not blocking inside virtual thread
Exactly what the title says.
Code:
The above is the only
Scannermethod call in the entire program, and that Scanner is the only one that exists as well.
I've never had this happen before in all my years of Java, and I'm stumped. I'm on JDK21.38 Replies
⌛ This post has been reserved for your question.
Hey @Haiku! Please useTIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here./closeor theClose Postbutton above when your problem is solved. Please remember to follow the help guidelines. This post will be automatically marked as dormant after 300 minutes of inactivity.
Virtual threads are always daemon threads
they don't stop the JVM from exiting
if you want the program to continue running, you need a normal (non-daemon) thread being active
No it's not that it keeps running while the program is stopped, it's that it doesn't block the thread and wait for input.
It just says "nope, nothing here" and throws instead of waiting for stdin to have something
💤 Post marked as dormant
This post has been inactive for over 300 minutes, thus, it has been archived.
If your question was not answered yet, feel free to re-open this post or create a new one.
In case your post is not getting any attention, you can try to use /help ping.
Warning: abusing this will result in moderative actions taken against you.wasn't able to reproduce on Java 21 Temurin 21.0.5
which distro are you using @Haiku ?
💤 Post marked as dormant
This post has been inactive for over 300 minutes, thus, it has been archived.
If your question was not answered yet, feel free to re-open this post or create a new one.
In case your post is not getting any attention, you can try to use /help ping.
Warning: abusing this will result in moderative actions taken against you.OpenJDK
Yeah I can't reproduce it on temurin either. I guess it's a bug in the distro. That's a first.
Can you show your whole program?
And what do you mean with it saying "nope, nothing here"?
Note that Dioxin's code has an additional
while(true) loop at the end after starting the virtual thread (for the reason I mentioned before)
Did you maybe create multiple Scanners?NoSuchElementException on the scanner when calling input#nextLineCan you show your full code that reproduces it?
Ideally a minimal reproducible example
Nope, only one. And the main thread is chugging away at other tasks while the virtual thread is running.
Since it's not reproducible on temurin I do think it's just a JVM bug
That is a minrep
What I posted
So you can reproduce it without anything instead of the
// ...?Yep
and you also never put a
.close() anywhere?Nope
Can you show the full main class and the output of
java -version on the JDK where you could reproduce it?It closes when the program shuts down, no sooner
?
I was just repeating that point, don't read into it
If you shared all the necessary code, the program is allowed to exit right away
I think even a
NoSuchElementException would in principle be allowed in that caseAh yeah good point
The while loop is the best way to simulate what's going on, it actually opens a swing window and does stuff there
But I've verified that the main thread is still running, not just the event queue
Show me a full main class and the output of
java -version that reproeudces the issue togetherSure just give me a few minutes, I'm afk
and your code above is not a reproducer because it's
startVirtualThread and not newVirtualThreadAh good catch
Though I wouldn't expect that to happen with normal JDKs
But honestly I'm realizing that it's an openjdk version I downloaded back when 21 was still new, and my exact same code works on temurin and breaks on openjdk, so I'm fully willing to chalk it up to a jdk bug and move on
Temurin is an OpenJDK build - just one of many openjdk/jdk vendors
which is why I also asked for the
java -version outputMaybe it's an updated version then idk
.
Alright give me a few minutes then
but I don't see it being a bug even if the thing you described happened
I don't think there's anything in the specs that doesn't allow closing
System.out in the normal shutdown procedure before killing daemonsWait, now that I think about it...
Ok give me a few minutes to check with an actual tested minrep instead of vaguely theorizing off-hand like an asshole
Alright, here's the actual error. You were right that the "minrep" I provided wasn't actually reproducible, and I'm sorry about that. I was in a rush to diagnose it since it failed during our test demo less than an hour before presenting.
I was also wrong about a couple of my assumptions, the main one being that it was JDK/OS-dependent. It wasn't.
I did however figure out what the problem was.
We were running it through the gradle console. There's no stdin on the gradle console.
I guess I thought it was inconsistent because I didn't realize when I absent-mindedly switched from my Application task to the gradle
run task
Thanks for the help yallIf you are finished with your post, please close it.
If you are not, please ignore this message.
Note that you will not be able to send further messages here after this post have been closed but you will be able to create new posts.
Post Closed
This post has been closed by <@67415933529894912>.