Spent some time on this. here is relevant part build.gradle.kts
apply(plugin = "java")
application {
mainClass = "com.example.Example"
}
//exec {
// standardInput = System.`in`
//}
I am using gradle 8.2
the code has a scanner that calls scanner.nextLine and it complains that there is nothing to read
exec { ... } would execute some program and for that wire System.in to stdin.
What you intended to do is to to configure the run task like that, so for example:
tasks.run.configure {
standardInput = System.`in`
}
Btw. you should not use the legacy apply(...) in a normal build script, but always apply plugins in the plugins { ... } block.
@Vampire thanks, it works, but I would like to be able to approach this better next time and there are some more questions
how did you find how to do this in the docs?
also, gradlew constantly updates the progress bar. is there a way to allow the jar to be put on the foreground? I find the progress bar annoying and gradlew flushes the stdout of the program every second
how did you find how to do this in the docs?
I did not find it, I know it. 
But well, what specifically?
You are running the task run, so you want to configure the task run.
The task is of type JavaExec, so it should be pretty clear.
The only caveat that is not really clear is, that the run task is special, because the Kotlin built-in run extension function wins if you just do tasks.run { ... } unless you take special measures like aliasing the task configuration accessor, or aliasing the built-in extension function, or using the configure call.
This detail is indeed not on the docs afair and should probably added to the application plugin docs as warning if someone would open a doc issue about it.
also, gradlew constantly updates the progress bar. is there a way to allow the jar to be put on the foreground? I find the progress bar annoying and gradlew flushes the stdout of the program every second
Well, the run task is just a task like any other, and while it is running, the build is running and so the progress bar is shown.
But as you only use that task to occasionally test, it should usually not be that disturbing.
You are not using a build tool to acutally run the program in production, do you? 
What you could do is to disable the “rich” console, for example using --console=plain. This will remove the progress bar, but also remove colors and some other things. But it might be what you want at the time you are using the run task to test your application.
@Vampire
Thanks for the response. I guess it’s not that clear on the docs alone and understanding what to do comes with the affinity with gradle itself.
for the run tasks, it’s actually part of an XY problem. The bigger problem is that IntelliJ uses this as the recommended runner for the “run” button on the top right.
Obviously there are some caveats as you mentioned, but I wanted to see if I can sort of fix the configuration so that I don’t have to set up a whole new one
I guess my final solution would to be configure gradle build as a prelaunch task and just run the jar itself. Would you agree?
I cannot agree as I did not really get what you meant with your last sentence.
For IntelliJ created tasks like YourClass.main() you should not need to do anything. IntelliJ is automatically doing the right configuration, I just tried it to be sure.
whoops, I did jump to conclusions
I’ll backtrack and explain from the very start
I felt like the intellij run console was laggy. so I did some measurements
The output is updated every 300ish milliseconds, and the input is sent to the program every 1000ish ms. I verified that it is from intellij after not being able to replicate that behavior by running the jar file using the java cli.
Then I opened up a different intellij project but with an intellij build configuration and the laggy behavior was gone as well, so I deduced it was gradle.
I am not sure how intellij exactly implements their task runners, but by limitation I mean these two things
Does this clarify things?
I see and now also understand what you meant.
I don’t see such delays, at least not that I could tell.
Do you also see such delays when you not run through IntelliJ, but through Gradle from the commandline?
And if such delays are there, you should maybe report it somewhere so that it might get fixed mid-term.
But yeah, if you have such delays and don’t get them fixed, configuring a Jar run configuration with a Gradle pre-task is surely one option if it helps you.
Or you could just switch off the Gradle delegation if your build is trivial enough that IntelliJ can do the right thing and you do not need some special things the actual build is doing.