«

On 20 Oct 2005 08:51:12 +0200, Gordon Beaton <> wrote or
quoted :

>If you can control the console input mode (for example, with stty on a
>unix-like platform) then you can turn off local echo as another poster
>has already suggested. I've posted sample code to do this several
>times in the past:

I don't think that would work in windows. Local echo suppression would
be a command to the command interpreter which is not even necessarily
running at the point your program is. If it works in Unix, that means
Java implements the console in a more native way.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

On Thu, 20 Oct 2005 08:33:00 GMT, Roedy Green wrote:
> I don't think that would work in windows. Local echo suppression
> would be a command to the command interpreter which is not even
> necessarily running at the point your program is. If it works in
> Unix, that means Java implements the console in a more native way.

Java doesn't implement the text console that it runs in on either
platform, the OS does. Java reads stdin from a file descriptor in both
cases.

It has nothing to do with the command interpreter either. The OS
provides the console as a logical device (e.g. /dev/tty on unix, con:
or something like that on windows) that the process communicates with
through the file descriptor. Changing the console mode is a simple
matter of configuring the device to behave differently (assuming that
it has that capability).

On Unix and similar platforms like Linux, there is a set of APIs for
configuring the console (unavailable to Java), and a command line tool
"stty" (which can be used either from within the Java application, or
in the shell prior to starting the application).

Potientially the mechanism should work on Windows if the console has
such a capability and there is a way to manage it from an application,
however I have no idea what facilities might be available. That
doesn't prevent me from posting a solution that is sufficient for some
users though.

/gordon

--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

wrote:
> Just to clarify, it is a console application - all input and output is
> done on the console. So JOptionPane/JPassWordField will not work.

Java is not well suited for console applications at all. If fact, it
provides nothing, absolutely nothing for a serious console application.

Consider

- Another language - seriously

- An additional, JNI based, platform-specific text API library like
JCurses, or

- to change the application to a GUI application.

/Thomas
--
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/...g/java/gui/faq
http://www.uni-giessen.de/faq/archiv....java.gui.faq/

On Thu, 20 Oct 2005 08:32:41 GMT, Andrew Thompson
<> wrote or quoted :

>( Your words carry the taint of 'premature optimisation',
>the way I read them. )

Poor old Knuth, when he dies will roll in his grave, when he learns
how his words have been interpreted so often to mean "Writing slow
programs deliberately is a mark of virtue." like the way people in
medieval times bragged about how rarely they bathed.

It is not wicked to know what will run quickly or slowly or to even
spread that knowledge. If you can optimise early without extra effort
that is a GOOD thing. That is not premature.

"Premature" does not mean "early" or "design-stage".

What Knuth was railing against was micro coding in optimisations that
a modern compiler does for you, making the code harder to read and
maintain, without even determining if that code was a bottleneck.


--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

On 20 Oct 2005 11:27:00 +0200, Gordon Beaton <> wrote or
quoted :

>Java doesn't implement the text console that it runs in on either
>platform, the OS does.

how do you know this?

Obviously the command interpreter is not there.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

On Thu, 20 Oct 2005 11:18:35 GMT, Roedy Green wrote:
> how do you know this?

Basic understanding of how an operating system works. Stdin and stdout
look the same for every process. Redirection works as expected,
without any help from the application. No process creates the
environment it's run within. Some experience with windows too, I'm
afraid.

I don't have an authoritative document to refer to if that's what you
mean.

/gordon

--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

Roedy Green wrote:
> On Thu, 20 Oct 2005 04:36:22 GMT, Andrew Thompson
> <> wrote or quoted :
>
> >> Just to clarify, it is a console application - all input and output is
> >> done on the console.
> >
> >What is that? A *rule*?
>
> One problem with using JPasswordField is as soon as you use even that
> one widget you will drag in a ton of related GUI junk that will stay
> loaded till the end of execution.
>
> I think the easiest answer is a little C utility to collect the
> password and stuff it in the environment where you can extract it and
> add it as a system property or argument to the command line.
>
> See http://mindprod.com/jgloss/environment.html

If you add the password to the command line then anyone on the machine
can see it (assuming Unix) by looking at the output of ps (another
extremely useful command-line tool).

John
http://schemaspy.sourceforge.net

Andrew Thompson <> wrote in news:JCI5f.23130
$:

> Roedy Green wrote:
>
>> On Thu, 20 Oct 2005 04:36:22 GMT, Andrew Thompson
>> <> wrote or quoted :
>>
>>
>>>>Just to clarify, it is a console application - all input and output is
>>>>done on the console.
>>>
>>>What is that? A *rule*?
>>
>> One problem with using JPasswordField is as soon as you use even that
>> one widget you will drag in a ton of related GUI junk that will stay
>> loaded till the end of execution.
>
> (shrugs) ..and what? It takes but a moment, and what does it
> matter if it loads a few Meg of classes that remain in memory?
> I'd posit that any program that crashes with OOME's when a
> JOptionPane is shown, is already suffering memory problems.
>
> ( Your words carry the taint of 'premature optimisation',
> the way I read them. )

I think you (and some other people) are forgetting that some platforms
simply do not have a graphical interface. It is perfectly reasonable (and
in fact quite common among expert users) to install Linux without
installing the graphical components. And you would still have a completely
functional multi-user, multi-tasking environment - just without the
windows. And without an underlying window manager, Java cannot show any
frames, dialogs, etc.

zero wrote:
> Andrew Thompson <> wrote
>>Roedy Green wrote:
>>>On Thu, 20 Oct 2005 04:36:22 GMT, Andrew Thompson wrote:
>>>
>>>>>Just to clarify, it is a console application - all input and output is
>>>>>done on the console.
>>>>
>>>>What is that? A *rule*?
>>>
>>>One problem with using JPasswordField is as soon as you use even that
>>>one widget you will drag in a ton of related GUI junk that will stay
>>>loaded till the end of execution.
>>
>>(shrugs) ..and what? It takes but a moment,
....
> I think you (and some other people) are forgetting that some platforms
> simply do not have a graphical interface.

Headless. No (not forgetting). I mentioned it on a variety
of other sub-threads you seem to have missed.

We are now talking about use of JOptionPane in other environments.

(And FWIW - I was never entirely clear, and no longer care,
if the OP's environment *is* 'headless')

Roedy Green wrote:

> On Thu, 20 Oct 2005 08:32:41 GMT, Andrew Thompson
> <> wrote or quoted :
>
>>( Your words carry the taint of 'premature optimisation',
>>the way I read them. )
>
> Poor old Knuth, when he dies will roll in his grave, when he learns
> how his words have been interpreted so often to mean "Writing slow
> programs ..

If it were 'slow', I would not recommend it.
What are your benchmark's revealing?
How much time does it take?

<but then..>
What is your definition of slow?
</but then..>