0

I know what the JPasswordField class does, and how/when to use it. This is not the question, just for clarity.

What I don't understand is why its functionality can't be part of JTextField: What problem would arise if they made getEchoChar/setEchoChar methods visible in the JTextField class? What exact situation they were trying to avoid in designing JTextField and JPasswordField as separated components?

In the docs, they say:

JTextField

...

The method setEchoChar and getEchoChar are not provided directly to avoid a new implementation of a pluggable look-and-feel inadvertently exposing password characters. To provide password-like services a separate class JPasswordField extends JTextField to provide this service with an independently pluggable look-and-feel.

and

JPasswordField

...

JPasswordField is intended to be source-compatible with java.awt.TextField used with echoChar set. It is provided separately to make it easier to safely change the UI for the JTextField without affecting password entries.

But I really was't able to understand what they mean (particularly in "avoid pluggable look-and-feel inadvertently exposing password characters").

Diego Queiroz
  • 3,198
  • 1
  • 24
  • 36
  • 3
    `JPasswordField` can return the password without creating a `String`, see the `getPassword` method. – MadProgrammer Oct 15 '19 at 03:04
  • This does not answer my inquiry (I know there are differences between JTextField and JPasswordField). The main point is that JPasswordField adds very small changes that could be added to JTextField without the need for a new component (there would be nothing wrong in having a method getTextAsArray instead of getPassword to avoid Strings). But they [Java Swing developers] decided not to do so, apparently as a security measure. I would like to understand these security concerns. – Diego Queiroz Oct 16 '19 at 13:03
  • It answers in part "why" there is a `JPasswordField`, the fact that it also "protects" against unintended side effects generated by other look and feels, as started in the docs, which may change the echo char, making the fields "present" the actual text, rather then the echo character as intended. The larger problem is, Swing was designed over 20 years ago, hasn't seen a major update in over 10 and the original designers have moved on. So most the answer you're looking for will be guess work and conjecture on the part of the community. – MadProgrammer Oct 16 '19 at 21:27
  • So my "guess" is, `JPasswordField` prevents other look and feels from mistakenly unmasking the password – MadProgrammer Oct 16 '19 at 21:27

0 Answers0