Seperate threads for input

[deanus]

Hi,
I'm doing a project with java using the console and I'd like to perform some actions (such as printing to the screen etc) while waiting for input. I was planning to accomplish this by using unbuffered input, by polling the keyboard and performing other actions alternatively, but apparently retrieving unblocked input from a console-based java application is close to impossible (I've tried using JLine but it was way too complicated for me and I still did not get what I wanted).

I was thinking maybe there's a way to use the normal System.in.read() functions for input and performing other actions at the same time by using 2 seperate threads, but before I bother diving head-first into the whole topic of threads, I'd like to know is this possible?

I'm using BlueJ as an IDE and Windows OS, and I'm pretty sure I won't need to run this application on other platforms, so platform-independence is not an issue as long as it runs on windows.

Thanks,
Dean

[JamesCherrill]

These other actions (eg "printing to screen") -
1. Are they a response to user input, or do they happen at various times independent of user interaction?
2. Are they "long running", eg taking more than 1 second to complete? If so, why?

[NormR1]

printing to the screen etc) while waiting for input.

Could that result in output and input being mixed together?

[deanus]

The "other actions" I was talking about have nothing to do with the inputting. Basically when the program is "idle" and the user is in the main menu, it will check the time and display some alerts, while waiting for input from the user. Problem is, if it's waiting for input then it can't monitor the time and print on the screen, and vice versa.

I've just come across another alternative, that of building the application using GUI instead of the console. That way I can use unbuffered input. Do you guys think it's worth it? If yes, do you have any suggestions which is the simplest GUI package out there which supports unbuffered input?

[NormR1]

What do mean by "unbuffered input"?
That sounds too close to the hardware for a Java application.

What are your objectives with this I/O?

[JamesCherrill]

What you describe sounds like 2 threads to me - one in a loop waiting for user input, the other doing whatever else.
GUI in ordinary Java means Swing. Swing has its own thread for all GUI activity, so that would be a way of adding a second thread. However, if this is a learning exercise than I would suggest ignoring Swing threads for the moment and just writing your own 2 thread application. What you learn will be invaluable later (including understanding Swing threading).
When you say "check the time" I hope you're not thinking a loop that checks the clock. Have a look at java.util.Timer to manage tasks that have to be processed according to the time.