java.io.Console.readPassword turns echoing off, prompts for a password and reads it, then finally turns echoing on. Instead, it should return echoing to the state is was in at the beginning of the method.

I discovered this when running in an emacs shell, which handles echoing itself and turns echoing off in the subsidiary shell. After a Java process reads a password, echoing in the subsidiary shell is turned on, which results in double echoing after that. But any shell that has turned off echoing will be disappointed if `Console.readPassword` turns echoing on.

The fix seems to be to use the saved value of `echoOff` (e.g., from http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/65464a307408/src/java.base/share/classes/java/io/Console.java#l315) to set the state of echoing at the end of `Console.readPassword` (e.g., at http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/65464a307408/src/java.base/share/classes/java/io/Console.java#l328). Otherwise `echoOff` is a write-only variable, except for the use in the registered shutdown hook.

This issue can be demonstrated in a regular shell by turning off echoing in the shell (e.g., `stty -echo`) running a Java application that uses `Console.readPassword`, and then seeing if echoing is still off in the shell.

(There is another emacs-related bug here, in that turning off echoing as is done by the implementation of `Console.echo(boolean)` is not sufficient to disable echoing in emacs shells. But I accept that that is an emacs problem and probably much lower priority. Though, other applications (e.g., ssh-add) seem to have figured out how to turn echoing off and tell emacs to read a masked password from the mini-buffer. But that is a different problem.)