Re: Trouble with custom InputStream being used by Readers
On Tue, 5 Aug 2008, Chase Preuninger wrote:
Well how does any other console stop blocking so that a BufferedReader
can stop buffering? Does it just return -1 when it has more data. But
what if it acquires more later on?
I suspect, but am not certain, that Daniele is wrong about
BufferedReader's behaviour.
Also, if you could quote the post you're replying to, that would help
those of us not using Google Groups etc immensely. Thanks,
Anyway, the two problems i see in your code are the busy-wait in read()
and the fact that you're piling up an ever-increasing amount of chars in
your buffer (including all the chars that have been typed in and then
read, and which will never be looked at again).
My strategy would be not to write a custom stream class at all. Instead,
use PipedInputStream and PipedOutputStream. Wrap the PipedOutputStream in
a Writer, then write an ActionListener that handles events by writing the
text to the writer. Like so:
public class ConsoleUtil {
public static InputStream getInputStream(JConsole console) {
OutputStream out = new PipedOutputStream() ;
String charset = you figure this out ;
final Writer wout = new OutputStreamWriter(out, charset) ;
ActionListener al = new ActionListener() {
public void actionPerformed(ActionEvent e) {
// is this really right?
wout.write(con.input.getText()) ;
wout.write('\n') ;
}
}
console.input.addActionListener(al) ;
console.enter.addActionListener(al) ;
return new PipedInputStream(out) ;
}
}
tom
--
Formal logical proofs, and therefore programs - formal logical proofs
that particular computations are possible, expressed in a formal system
called a programming language - are utterly meaningless. To write a
computer program you have to come to terms with this, to accept that
whatever you might want the program to mean, the machine will blindly
follow its meaningless rules and come to some meaningless conclusion. --
Dehnadi and Bornat