🚀 go-pugleaf

On Tue, 13 Jun 2000 15:54:51 +0200, Jeroen Zwartepoorte wrote:

> I'm trying to have System.in point to a JTextArea instead of
> the command prompt. To accomplish this, i've written my own
> InputStream class. The class works partly: System.in.read()
> does return character typed in the JTextArea, but when i
> use BufferedReader.readLine(), the method never returns
> (System.in.read() DOES return '\n' characters).

You do not show the code that points System.in to your input stream 
object or the code creates the buffered reader.  My guess is that your 
problem is with this code.  If you post it, I will take a look.

I have a few other comments:

You use a stack to buffer the characters that have been read.  If someone 
were to quickly type "ABC" before any of the characters were read, the 
input stream would return "C", "B", "A" in that order.  I think you 
should be using a queue rather than a stack.

You synchronize the code that adds a character to your buffer, but not 
the code that removes a character from the buffer.  I don't believe this 
will help if you do not do it in both places.

The synchronization will probably not cause a problem as written, since 
you are using a Stack, which extends Vector, which is synchronized.  But 
if you change this to a queue of some kind, the synchronization will be 
important.

Your code currently polls in the read() method, waiting for a character 
to be added to the buffer.  A better approach would use wait() and 
notify().  Information on using wait/notify is available at the following 
URL.  Note that the URL is too long to fit on a line, so clicking on it 
will not work.

    http://java.sun.com/docs/books/tutorial/essential/
        threads/waitAndNotify.html

Regardless of how you synchronize the threads, you will run into a 
problem if someone calls your read() method from the AWT event dispatch 
thread.  If the buffer is empty, it will block waiting for a character to 
be added to the buffer, but that can only happen in your KeyListener, 
which will run on the event dispatch thread.  So it cannot happen until 
your read returns.  You would have a deadlock.  You may want to add a 
safeguard like the following:

    if ( EventQueue.isDispatchThread() ) {
        throw new IOException(
            "Pl0InputStream.read() called from event dispatch thread" );
    }

You require a JTextArea as the input component, but I do not see anything 
that would require that specific component.  You could change this to a 
JTextComponent and make it a little more general.

Have you considered how your component / input stream will behave if 
someone tries to back up using the arrow keys and edit the text in the 
text component.  I am not sure how you will be using the text component, 
but my guess is that it will not behave as you would like.  You may want 
to consider catching just the ENTER key, and then stuffing the current 
line into the input buffer.  That would allow the user to edit the input 
and to repeat previous lines.

I hope this helps.

-- 
John P. McGrath
<JPMcGrath@fast.net>
<jpm@nscs.fast.net>