I dont understand, what else would be required apart from single
character console input?
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.
The line displine etc is handled by the jvm in order to get the
kbhit/getchar etc function enabled for the platform. The jvm is
abstracting that level, like it abstracts so much else from the
underlying operating system.
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).
Can you find me a platform that has consoles and java is ported to,
that doesnt have single char input as a native function already?
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.
Difficulty in writing java server applications means less java server
applications which in turn means less demand for solaris, you would
think somebody would make the connection...
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.
That's the point though the above is being repeated so many times, the
rfe was in the top 25, the top 10 i think, for 8+ years.
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.
Can you please explain what else is needed.
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
