<snip>

Think about how kbhit() in C is normally used, and shells in general,
and I think its safe to say that a multiuser shell environnment
stretches the imagination.

single-char input is a common enough requirement that should be solved,
period.

To be fair, kbhit() is highly useful in C - I used it alot - but it is
non standard. This C version wouldn't work on M$:

http://www.linuxjournal.com/articles/lj/0017/1138/1138l1.html

And no other language I know of - python. perl, for example - have an
OS independent kbhit like function portable accross *nix and M$.

More to the point, java's version of GNU readline, and jline, all use
JNI underneath.

Still, one wonders why threads and sockets can be portable, but a
simple character based escape loop cannot be. You can even manipulate
memory directly via sun.misc.unsafe. Unix signals are very platform
specific yet can be used via sun.misc.Signal.  Why couldn't a -D flag
or System property or such be used indicating OS or a terminal like
vtm100? Its not as big of problem as with C, because java really only
supports 3 platforms.

It was about nine years ago I implemented C kbhit() the first time, and
nine years and waiting for the java bug report to be solved...

iksrazal

kbhit() polls the keyboard. This is a big no-no in a multiuser,
multitasking system. You are going to burn CPU cycles just to check if
there is a character pressed on the keyboard. Typical kbhit() code looks
like:

   while(!kbhit())
    ;    /* burn CPU cycles like there is no tomorrow */
   getc(); /* finally get some character */

Also, you, or your application probably doesn't own the keyboard at the
time you run kbhit(). What should kbhit() do? Still tell you that a key
is pressed, even if you can't get it?

And, you typically can't poll remotely connected terminals if they have
a character ready. They either have send something or not, but there is
nothing to poll.

kbhit() has been left out of the C standard for very good reasons,
because not all IO systems follow a simple PC like architecture.

And to continue, there is more in a terminal driver than just delivering
characters unaltered. You need to get control over the driver and thus
over the terminal to successfully control character input. Controlling
buffering, handling/replacement of EOL and other characters, (escape)
encoded special keys, turning on or off parts of a keyboard (numeric
input field).

If you communicate with a real terminal, there is much fun involved.
Sometimes you want it one way, sometimes you want it to behave the other
way, and a generic "just look if a key has been hit" doesn't cut it.

And how do you know which particular setting of the driver a particular
application requires? If you stick with Unix termios, there are roughly
50+ configuration parameters. Some settings are more likely than others,
but there is a heap of stuff to go mad about.

Unix has a library on top of that, the very appropriately named
"curses". That one basically weaves together driver handling, and
terminal-specific configuration and control characters (using the
terminfo or older termcap database), and provides a slightly higher
level API (plus some stuff like fragments of a text-based windowing system).

Define "native". If we again take Unix for example, then a kbhit() is
not there, and should not be there. You do not poll on such systems. To
get a single character you have to first configure the terminal driver.
You can either do that with a library (e.g. termios, which is basically
a driver interface or e.g. the "higher level" curses) from within your
application. Or one sometimes can get away with configuring the line on
the command line with a tool called stty.

And until now we only talked about terminal input. Output is equally
fun, since sometimes you have to take timing into account so not to
overrun a terminal's buffer or CPU. Different terminals use different
sequences to color or highlight text, sometimes in the most crazy ways
(I well remember old HP terminals for having a horrible way of handling
highlighting). Different terminals provide different numbers of lines
and columns, scroll buffers, etc.

The Sun Java folks and the Sun Solaris folks apparently don't get very
well along. There was a famous memory leak some time ago, where the
Solaris folks bitterly complained about the Java release management, bug
 fix releases and how unsuitable Java was for their purpose.

Now you know why people don't take things like Sun's bug parade very
serious. Sun anyhow does what they want. They rather preferred to add a
skinnable L&F or generics or whatever to the language, than taking care
of these things.

For a start what is in curses, like facilities to open and close a
terminal/console connection, to configure the driver in a suitable way,
to map escape sequences to standard key codes, to generate the control
sequences needed by a particular terminal, to drive the timing on the
line. To get information about the number of lines and columns, etc.

Java will give you an extra headache, since you have to know the
character code which comes from and goes to the terminal or console.
Everything inside Java is Unicode, but that's not what a terminal /
console will likely speak.

Curses is really not great, but a standardized curses version in Java
would be better than nothing. But expect Sun to implement yet another
LAF than doing something like this.

/Thomas