Date: Wed, 21 Aug 1996 09:52:10 -0700

Subject: Java API issue

Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-MD5: hs6xVqxfhf1l05aG+h0k5Q==

Another one for the stack...


------------- Begin Forwarded Message -------------





Subject: Java API issue
Date: Tue, 20 Aug 1996 15:27:42 -0700

If you do get around to the Java API this year :-) one issue I'd like to see 
addressed if possible
is FileInputStream.read();

In particular, where input stream editing fits in.

This came up when I wrote a SerialInputStream class that read characters from a PC 
serial
port. I wanted to connect System.in and System.out into the serial port. So I created 
a 
buffered stream with new BufferedInputStream(new SerialInputStream("com1:9600/8n1"));
and assigned it to System.in. That worked sort of but there were two problems:
	1) Line editing wasn't dealt with, (while ^h echoed, it also went upstream.)
	2) spontaneous input wasn't possible (aka raw mode) as in {
		while (true) {
			if (in.available() != 0)
				return in.read();
			doSomeOtherThing();
		}

This isn't an issue in Applets (unless you create interactive serial streams for 
them) but it
is a major compatibiltiy issue with Applications. 

This is particularly true when different platforms specify different line editing 
disciplines
(is ^h a delete or is <del>?, what does ^u do? etc)

There is another related can of worms which is supporting several applications 
running in
the same VM with different ptys. I'm sure some of this has come up in the Kona work
and probably been dealt with. I hope it gets fed back into the API.

Ideally, I'd think that line editing and the notion of a controlling pty could be 
encapsulated
in a java.lang.Console class. A partial definition might be:
public class Console {
    /** Create a new console connected to these two streams. */
    public Console(InputStream in, OutputStream out);

    /** Createa  new console connected to 'stdin/stdout' */
    public Console();

    /** read one line of input (with line editing) from the console. */
    public String readLine();
   
    /** print a line to the console */
    public void printLine();

    /** return this consoles input stream */
    public ConsoleInputStream inp();

    /** return this consoles output stream */
    public PrintStream out();

    /** return this console's error stream */
    public PrintStream err();
}

ConsoleInputStreams could define the line editing discipline. The reason we have
to combine both an inputstream and an output stream into the class is that for
line editing the user may type ^r and expect the current input buffer to be replayed.
The console has to know where to send it. Thus the constructor for ConsoleInputStream
would take both an InputStream  customer  and an OutputStream  customer .

This will also solve the problem that other threads/applications in the same VM can
stomp System.in and steal the tty from another application.

--Chuck
------------- End Forwarded Message -------------

N/A

Designing a termio-style TTY interface for Java is an incredibly difficult
problem because it would have to unify the low-level TTY interfaces of a wide
variety of systems.  The Java platform is aimed at the creation of GUIs and
command-line tools; rewriting vi or emacs, or supporting any sort of
termcap-style interface, is just not a priority.  If you really need this
functionality, you can always write native code.

--   xxxxx@xxxxx   2000/3/9

I know of a UNIX workaround using the stty
command.  If you run "stty -cbreak" before
the Java application, System.in.read()
will read single characters.  I have found
no command that would work in a Win32 DOS
shell to produce the same result.  It does
work very well in UNIX, however, and if
anyone's interested I can post code that
works with "stty -cbreak".
For general info on reading single
character input in UNIX, see
http://www.cosy.sbg.ac.at/comp/os/unix/faq-q/cuq-faq-q4.1.html
Hope this helps,
Chris Evans

Ugh, what a disappointing response.  Shouldn't the JCP make it possible for
an interested party to do this up right?  This is a solved problem in UNIX,
I don't see why it should be so impossibly difficult to implement something
reasonable.. if you're on DOS or Windows or OS/2 you use their native stuff, if
you're on UNIX use termcap, if you're on a Mac OS X box you do likewise..
what's so hard?

Even if this sort of thing wasn't in the core API's, it is too much to ask that
everyone re-invent this functionality.  We have spent five years working on
an RMI-based system for directory management, and to be told that we
simply can't write Java tools for reasonable functionality on the command
line is really harsh.  If you guys at least fix 4050435 I'll be able to live,
but for Sun to decide that their platform is not intended for text usage
is incredibly myopic and arrogant.