.I need the ability to safely prompt for a passphrase, of arbitrary
length, without echoing output.  This is like the getpass(3C) does,
but that truncates the input string and so calling that isn't  customer 
enough to address the real requirement.

Not all applications of Java can assume that a GUI is available,
so AWT's setEchoChar stuff is not usable for this problem. 

N/A

In addition to supporting getpass-like functionality, we should also look in to
supporting simple line-oriented editing operations.  These are necessarily
somewhat platform-specific (e.g., Linux readline() vs. the DOS command prompt),
but the addition of this feature would make it much easier to write simple
non-GUI, command-driven programs.

This RFE does not propose to define a general curses-like facility, which would
be much more complex and, in a world where bitmapped displays are ubiquitous,
arguably unnecessary.

Under consideration for Tiger.  --   xxxxx@xxxxx   2002/2/20
Will provide a simple password-prompting facility much like that
available in C as via the getpass(3C) function, in Mustang.
Posted Date : 2005-09-27 20:45:21.0

The need, IMHO, is more to provide a mean to read one character at a time, with
or without echoing (programmer selectable) each character typed.
This would give a base to work on enhenced class providing function like
getpass(3C) or anything else having to do with console input.

What we need is something at base with the functionality in the code sample
 (only a few lines of JNI!) I posted for 4236007.  It's not rocket science,
guys!

We have had the need many times to read characters from 
System.in as they are typed, rather than waiting for 
RETURN - along with the need to turn local echo on or off.  
IMHO, this is a huge oversight in Java.  We have been 
forced every time to use C or C++, making it that much more 
difficult to "write once, run everywhere"

Ugh, it is awful that this isn't available.  If I have any Java text mode code that needs to
prompt for a password (and I do), then I have to turn off char echo in the shell
script that invokes my Java program.. and then I have to *never* ask the user
a question other than for passwords, or else the user enjoys the weirdness of
not having char echo on.

At this point I'm afraid the only thing I can do is to maybe write an expect script
that knows what kind of questions the java code might ask and when to turn
off charecho.

Yuck, yuck, yuck.  Fix it.

It is ridiculous that this bug has not been addressed in
four years.

Well if you are on Unix, have the users telent into the 
app, then you can use the telnet control characters to turn 
echo on and off, Thats is what I did

Well,
the weblogic applicaiton server 6.1 beta which is built in 
java prompts for the password on the DOS command window and 
mask characters (*) appear as you type the password there.. 
don;t know if this is in java or any native lib is used.

For god's sake fix this problem NOW!  How long has it been?  4 years?  This getting 
ridiculous!  Is this the kind of product we can expect from SUN.  I am hugely 
dissapointed.

This is really necessary.  It can be clean too:

if (System.in instanceof InputTerminal) {
   InputTerminal it = (InputTerminal) System.in;
   it.setEchoEnabled(false);
   it.setInputBuffered(false);
} else {
   System.err.println("You don't have a capable terminal.");
}

The same thing could be done for 'OutputTerminal', adding cursor relocation capabilities, etc.  If the JDK was developed more openly, I'm sure this feature would already be present.

Yup, this is really needed on the server side with any 
application that involves security.  It pains me every time 
I attempt to write a security-related server product in 
Java and don't have the ability to read passwords without 
going to JNI...

This is an important feature to have. We cannot expect 
everyone to use JNI.

I have tried uncessfully a workaround to this problem with 
JNI.  I am running red hat linux 7.2.  even though the 
native getchar method is being called, the input goes to 
the terminal and getchar returns -1.  anyone know why this 
might be?

Reading characters without echoing is the most important of the goals mentioned in this RFE.  Please include 
it in Tiger (it's getting my votes).  

The proposal to support line editing would also be incredibly valuable.  Many, many people use command 
lines every day, for server administration, build management, and all kinds of things - Java should support 
these uses (and users)!  Two significant tools in the Java community that would be greatly boosted by 
these features are Ant and BeanShell.  There may not be as many Java developers as Java users, but the 
Java developer community could really use these features.

WORA
Write Once Run Alot of places but not all of them because 
who would dream that anyone would want to write a console 
application?  Huh, people still use telnet? and SSH? Your 
kidding, right?  I'm running win2k on my cisco 5600 router 
at home!  no need to telnet, or write a telnet app, or 
anything that i can access from the router, thru a telnet 
session, on a *nix box, and use to do cool router stuff, 
and...  fine, I'm done ranting.   Fix this problem.  This 
is not a bug. This is a FAULT.  This is reason enough to 
NOT use java.  Geeze, mac never had a command line till 
osX, and look where it got them, 3% market share.  Wake up 
people.

I realise that there is a lot of excitement about using 
Graphical User Intefaces but one cannot overemphasise the 
power of the console.

I think it is a shame that a fundamental function like this 
has not been included NATIVELY with Java. I feel that it is 
even worse that it has not been dealt with in 5 years!

I have written a compact JNI class that addresses this bug. 
It has been tested on Windows, Linux and Solaris.  If anyone 
is interested in obtaining it please send me an email.

I believe, Password masking is really essential whenever we
try to develop a command line interface for any real world
application. I wrote a JNI program which does this, but then
my program depends on c availability and i can no longer say
that you just need java and nothing else.
Can you please treat this bug with high priority?

I concur with the general feeling of this posting history. 
How the heck can sun have not fixed this yet??

Good comment.but kindly elaborate this please...

Actually it would also be useful to create a
java.awt.Component and javax.swing.JComponent which act
like consoles (they could provide console functions to another
thread, for example).

I have already created very nice Java components which
provide this capability (and many others), as the previous
comment suggests.  They will be released as open-source in a
matter of weeks; I'll post the URL when that happens.

Took longer than expected to get everything online, but a 
beta version of the Enigma Console API (which supports 
password input, color changing, and tons of other features) is 
now online at http://www.ethannicholas.com/enigma/

Check out this solution that was posted recently on the 
javasoft site.

http://java.sun.com/features/2002/09/pword_mask.html

I guess this missing feature explains why jarsigner shows your 
password right on the screen ?

If I were Sun, I'd relate this bug to the 103 votes for 
the "closed, will not be fixed" collection at:

java.io.BufferedReader.readLine: ... not ... with System.in ...
http://developer.java.sun.com/developer/bugParade/
bugs/4071281.html

Of the related bugs, only
http://developer.java.sun.com/developer/bugParade/
bugs/4615032.html
"is not available on the Bug Parade at this time".

Write once, run anywhere...but only if a GUI is present?

Because of Sun's ownership of Java, one would have thought 
that simple terminal I/O would have been part of the design
manifest since day one owing to the terminal orientation of
UNIX.

If Swing coould be provided to allow platform neutrality for
graphics I/O, why can't the bright people at SUNW devise a
means for simple terminal I/O. As others have pointed out, it
need not have the complexity of curses, just provide a way 
for we Java developers to get a keystroke, for goodness sake.

The Enigma Console API (which solves this problem!) has been
updated to version beta-0.2.  It is freely available under
the GPL and may be downloaded from
http://www.ethannicholas.com/enigma/

The best solution which i've ever seen, is found at
http://sourceforge.net/projects/javacurses/ which is a very
nice,little text mode windowing api for linux/win32.

The Enigma Console does NOT solve this problem. It is based 
on SWING and is not a simple plain terminal io package. While 
a couple of people suggested what Enigma provides would be 
useful, it is not a non-GUI solution.

200 Votes and it still isn't addressed in 1.4.2beta.  Will this 
ever get implemented.  Looking at the votes for other bugs 
that were fixed in this beta there was only one with more 
votes, 312 votes  4616580 java_plugin  bridge  Support for 
Active-X Bridge.  Again, if you need this functionality contact 
me. I have written a compact JNI class that addresses this 
bug. 
It has been tested on Windows, Linux and Solaris.  If anyone 
is interested in obtaining it please send me an email.

If this does get done, can a commitment also be given to 
adapt the keytool and jarsigner tools from the JDK to use 
them?  I hate having to type my password in the clear and 
putting it on the command line is worse (because that's 
easier to snoop from other programs.)

Another application in desperate need for this
http://ant.apache.org - security should be a priority not
just for Microsoft...
see ant's bug report
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6687

I've found a workaround for jarsigner only: I wrap a shell-
script round it that adds calls to the Unix 'stty' utility around 
it, like this (without the error checking...)
  # Switch the terminal into no-echo mode, but keep newlines
  stty -echo echonl
  jarsigner "$@"
  # Switch the terminal back to normal mode
  stty echo -echonl
It's not a general solution, but it is enough to stop me from 
having to type my password right out where anyone can see 
it, which was the immediate problem...

If this were fixed, the strange 
http://java.sun.com/j2se/1.4.1/docs/tooldocs/windows/keytool.html#PasswordWarning
would no longer be necessary.

Six years and counting... 

Virtually every first year university course involves writing 
console apps.  Reading from the console is a mission for a 
first year student.  

Little wonder that the university I am at uses pascal/Delphi in 
first year and then switches to Java in second year only.  

Meanwile MS is gloating over how much more suitable C# is 
for first years.  I'm not exaggerating, they actually are using 
this as an argument.

It's a real need !

Six and a half years, and still counting. This is absolutely
the most pathetic of the bug entries I've seen to date.

Having to use JNI just to hook into kbhit(), getch() and getche
() is overkill. PLEASE sun, put these functions into System.in

For Solaris (at least, and it'll probably work for most
other Unixen):

// Retrieve terminal device name
Process p = Runtime.getRuntime().exec("ps -o tty=");
p.waitFor();

InputStream is = p.getInputStream();
StringBuffer sb = new StringBuffer(80);
int c;

while( (c = is.read()) != -1) {
  if ( c == '\n' || c == '\r' ) {
    break;
  }
  sb.append((char)c);
}

// Turn off echo for retrieved terminal name
p = Runtime.getRuntime().exec(new String [] { "sh", "-c",
"stty -echo </dev/" + sb.toString()});
p.waitFor();

---

Apologies for typos

-Dave

opened in 1997, and this  is still not available?

BTW -- the above seemed to work for Linux, for AIX we
needed to change "sb.toString()" to  "sb.toString().trim()"
and for HP, I needed to change the first command to:
   sh -c "UNIX95=1;export UNIX95;ps -p $PPID -o tty="

Sun - PLEASE FIX THIS BUG!!!!

I finally got around to setting up an open source project 
for my JNI solution. I'm happy to incorporate any 
changes needed to support additional platforms. 
Here's the link: http://sourceforge.net/projects/jmi

It seams Tiger haven't fix this bug.
Should it last 7 years or even longer?

dnavas: You could just use /dev/tty (which is a magical 
device equivalent to your current controlling tty) instead 
of hacking around with ps.  Much easier.

Freely redistributable Win32 and Linux (x86 build) code that can be used for this at http://www.windsong.demon.co.uk/getchsig.zip - enjoy.

Yes, I most definately agree, this must be implemented.

The update of http://java.sun.com/developer/technicalArticles/Security/pwordmask/

to add security against string object persistance.

Now how about setEcho off and setBuffering options?

I just hate sending jni code for a missing requirement of Java.

If you add the simple ability to read individual characters from stdin, instead of waiting for the user to press ENTER, it would solve everyone's trouble and save you (Sun) lots of development time coming up with specific implementations that read passwords, etc. We can do that, if you provide us with the tools :)

If this got added we wouldn't have Microsoft using this:
www.cs.arizona.edu/people/reges/sigcse/csharp.pdf 
to sell C# to universities.

This RFE gets my vote.

The URL posted by uncleHohoho is eye-opening.  I would think the mere fact that the lack of good console input is being used by MS to leverage C# over Java in Universities would be all the justification needed to get this fixed ASAP.

This is pretty embarassing.  Why can't we even implement halfway smart command line apps with Java?  Not all apps want (or need) to use AWT or Swing.. or even support it!

Bah!  Can't believe this is still open 7 years later.

Ouch. After a few hours of digging for a stdin character-by-character read method I finally hit this bug/missing feature description. It is indeed hard to believe that it hasn

(... previous comment got truncated !?)

It is indeed hard to believe that it has not YET been implemented since it was first reported in 1997!!!!

Yup .. I agree this is really silly.

First post in 2005 for this bug!  Yeah!  And look at that, only a few more months until this one hits the 8 year mark!

I just started development of a command line interactive RDF editor which leverages Jena <http://jena.sf.net>, and I've wanted a way to do fancy things like moving forward and back in the line typed (wow!) and command history and the like.  If I'm not mistaken, this bug pretty much crushes such functionality, unless one wanted to get dirty with JNI.  Thus, it gets my vote!

Can I vote for this one twice?

I was shocked when I knew that Java was not able to read by itself just one character from a console while not waiting for an <enter> key to be pressed. This is extremely basic and useful. (Even right now I

(Previous message got truncated)
(Even now I'm wondering if I'm wrong with my understanding. I hope I'm wrong) This has my vote.

Getting closer...

This bug is totally unacceptable. I have tried two plain-java workarounds which I have published on my personal site :

http://hkara.club.fr/java/PasswordWorkarounds.html

I program a lot with Swing which has nice features, but I also frequently need that administrators launch java programs from their terminal; and when it comes to that
my programs look like they were designed in the 60

from bug 4417626:
imqcmd prompts for the administrator username and password if  the -u and/or -p options are not specified. We will continue to echo the username when typed in. For the password, we will not echo any characters when the password is typed in if the native code to do this is available.

can we have beta code for now?
can we have an API for what is used in imqcmd?
I would even take even a pre-depricated API.

ping
ping 
ping

what is the progress?

hey, aint you gonna fix THAT?

This RFE is 5th in the top-25 list, and is now over EIGHT YEARS OLD!

Is this ever going to be resolved?

+1 not that it'll do much good. 

i need this. my application should run on DVR devices and tunneled through SSH. what would you suggest ? 

this bug is from 1997. i wonder how people debug large Java applications without debug menus and advanced (console only) simulations. 

+1 
i was going to move away from Java anyway. this is just one more reason to do this

...sorry for multiple posts

this RFE holds slot #4 in top 25. for me it is pain to wrap TTY around Java Application.

Please, please... this is such an important enhancement that could easily be implemented without breaking ANY existing applications -- can't we update it in a minor release of 1.5?  Adding my vote.

Man... What’s so hard about solving this bug? My vote on this

Suggestion, JDK has a publicly viewable source.  Someone can fix it and send the patch to Sun.  They appear to have been asking for patches!

I develop an interpreter for Rhythm which work in RAW mode. The source is in Eiffel, I would be glad to port to Java but there's no RAW mode available.
I vote three times for that feature but I don't understood why Sun experts don't explain why it was very unhappy to add this basic feature.
Since, I wrote a compiler for Rhythm : http://cdridi.club.fr
 which doesn't need RAW mode ... but people who are interested in OOP with RAW mode enable can write me
at the end of my web page.

I would really like this feature as well.

The funny thing is that THIS bug DOES NOT appear on Top 25 Bug list, even though it has enough votes to be listed as #2 there.

4050435 shows up on the rfe list.

Please see:

http://bugs.sun.com/bugdatabase/top25_rfes.do 

There is a working, open-source implementation for readline on SourceForge that could probably be used as a starting point.

http://java-readline.sf.net/

Scott

8 and a half years... now that's working on internet time... %|

Hooray!  Finally a fix!  Now when do we actually get to use it?  "mustang(b57)" means this will be in the final release of 1.6, I think... so does anyone know approximately what quarter that will get a final release?

Now wait just a second. Does this mean that all we're getting is a getpass(3C) function after all these years of waiting, or are we going to get the ability to read input character by character?

Something tells me we're about to get really disappointed.

If all you are providing is getpass functionality, then I am amazed.  Come on folks!  How hard can it be to provide single character input with or without echo such as the VERY FIRST comment to this issue describes?  Please tell me I'm wrong, and that you are providing single character input with or without echo.
Listen to your users!  Listen to them!  This issue has been outstanding for a very long time.  If it is going to take this long to address a well voted issue, then at least provide a real solution.  WE ARE *NOT* ASKING FOR CURSES OR ANY OTHER SUCH THING, just for the simple ability to read a single character at a time with or without echo.  Once you give us that ability, let us deal with the other issues.  We can figure out ourselves how to output terminal escape sequences if we need to, we can develop our own curses like libraries if we need to.  The point is, these things are *possible* for us to do if we have this one simple facility, whereas right now they are *impossible* without resorting to JNI.

http://download.java.net/download/jdk6/docs/ have not been updated yet, holding off on comment until next snapshot becomes available.

https://mustang.dev.java.net/
http://download.java.net/jdk6/

In other news, pigs flew today.

It seems to be documented here: http://download.java.net/jdk6/docs/api/java/io/Console.html

I guess this RFE is closed and will not be reopened. It has been solved by implementing the specific request made in "Description", but it does not solve all the issues mentioned in the "Synopsis" and in the first part of the "Evaluation". Furthermore, there are several related bugs that have been closed as duplicates of this bug even though they focus on the unbuffered I/O support (like  4717813 ).
Does this mean that we should open up a new bug and start the voting all over again?

Everyone, please go vote for #6351276. Console does not support reading individual characters!

Hey, this feature would be greatly helpful. But cant wait till mustang release. Is there any updates (now it is jdk1.5 update 6) in pipeline for jdk1.5 ? and if there is one will or can this feature be included in that?

I understand that is got implemented in Mustang. But this is not still sufficient. Whether an echoed prompt or a non echoed prompt, the data will be read to the only on carriage return. I still don’t have a getch() functionality.