JDK-4008589 : TTY: Input stream editing (line disciplines, ptys, raw mode)
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.0.2,1.2.0,1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,windows_95
  • CPU: generic,unknown
  • Submitted: 1996-10-11
  • Updated: 2000-03-10
  • Resolved: 2000-03-10
Related Reports
Relates :  
From jag@doppio Wed Aug 21 09:50 PDT 1996
Date: Wed, 21 Aug 1996 09:52:10 -0700
From: jag@doppio (James Gosling)
Subject: Java API issue
To: dbowen@doppio
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-MD5: hs6xVqxfhf1l05aG+h0k5Q==

Another one for the stack...

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

From ###@###.###  Tue Aug 20 15:29:37 1996
From: Chuck McManis <###@###.###>
To: "'###@###.###'" <jag@Eng>
Cc: "'###@###.###'" <###@###.###>
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 
port. I wanted to connect System.in and System.out into the serial port. So I created 
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();

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 
(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 
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 object and an OutputStream object.

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.

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

PUBLIC COMMENTS Request for input stream editing, Console class.

EVALUATION 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. -- mr@eng 2000/3/9
175-08-03 0