On Wed, 23 Jun 2021 17:20:27 GMT, Alexander Zuev <kiz...@openjdk.org> wrote:
> 8268775: Password is being converted to String in AccessibleJPasswordField src/java.desktop/share/classes/javax/swing/JPasswordField.java line 634: > 632: Arrays.fill(password, getEchoChar()); > 633: String text = new String(password); > 634: return new AccessibleTextSequence(0, password.length - > 1, text); So the accessible text is just the right number of "echo" chars. And you are still calling getPassword() just so you can find out the length. Then it is over-written. There's a really tiny window after getPassword() and before Arrays.fill() when the clear password is still there. The number of "char"s isn't the same as the number of "characters" if there's a non-BMP code point in there .. perhaps these are not allowed by this class .. but it makes me wonder how much if having the exact number of echo chars as the actual password is important. I wonder how many text-to-speech readers can say "bullet" for a unicode bullet character ? If it weren't for all of this (the class and the getPassword() method being non-final I'd suggest you look into a way to pull just the length rather than the actual chars. ------------- PR: https://git.openjdk.java.net/jdk17/pull/127
