I'm using the LWJGL for a new project, but it's not for a game, exactly. The point is that this project is meant to take in lines from the console piped from some other device. It's not important what the other device is, but the point is that a few times a second this device will write a string to the command line, which is then piped into my program.

What's the best way to handle these string inputs? Provisionally, I am using the scanner, calling "scanner.nextLine()" to read the next line. The problem is that this will pause the program until a new line is written onto the console, which is NOT what I want.

I would rather have the program run as normally, at 60fps or what have you, and IF a new line was written to the console, to THEN call a method using that new string as input.

Oh wait, alls not well. I just realized that even though my window closes when I click "x", my program keeps running, because in one thread I'm still waiting for scanner.nextLine(). When I type something into the console, the program ends as it should. How do I get my program to end before nextLine() gets what it wants?

then, when I created the thread, I would pass the running boolean = false from the main thread to it before closing, so that it wouldn't run it's while loop, as the main thread would be stopped, so you would never sleep the secondary again. This would look like this:

All I needed to do was insert "System.exit(0)" when I wanted the program to stop.

I don't know if others would agree, but an endless while loop is a bit of sloppy code. It's best to terminate your loops gracefully using a boolean flag, as bilznatch has mentioned. Either way... whatever works for you. EDIT: Or does sc.nextLine() block? I see what you're doing there. Sorry.

All I needed to do was insert "System.exit(0)" when I wanted the program to stop. Forgot about that command, thanks!

Look into Thread.setDaemon(). When you mark a thread as a daemon thread, it will not prevent the JVM from closing when your user thread(s) terminates. It addresses the situation being discussed without having to throw interrupts, juggling booleans, or forcing a JVM exit. Just make sure you call the setDaemon method before starting the thread.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

Pretty much. Their main purpose is to service user threads, therefore once all of the user threads are dead, they have no reason to stick around and the JVM happily disposes of them. The main caveat to be aware of when using them is that there is no finalization performed by the JVM when it kills a daemon thread so any cleanup code you may have in a "finally" block will never get triggered. This limits their usefulness somewhat, but it presents a straightforward and practical solution for the situation being discussed.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org