Chris Uppal said:
Even with those cautions, I doubt whether JPasswordField counts as "not leaving
in-memory traces", not when there's a copying garbage collector in the system.
Indeed. On the other hand (but for the problems below) it would at
least be possible to minimize the probability. So long as the object
were not kept for long, it would be unlikely to copied too much, and the
younger generations would be likely to be overwritten quickly with newly
allocated objects.
Problems with copies due to virtual memory in the operating system are
equally difficult and far less transient, but are also even less likely
to happen so long as the data is disposed of quickly.
Actually, looking at the code, I'm not too impressed.
Looking at the code, I'm not too impressed, either. I had assumed that
JPasswordField used a custom implementation of Document that prevents
discarded copies of data, and that getPassword() returned the actual
underlying char[] used by the Document implementation. It turns out
that's not the case; there is no special-purpose document, and
getPassword() just makes another copy of the text. This makes
getPassword basically useless; may as well use getText instead.
Except that getText is deprecated. That, then, is the kind of arrogance
in API design that gets my hackles up from Sun occasionally. Even if
JPasswordField and getPassword() were implemented properly, this kind of
trick would be unnecessary in 99% of cases where JPasswordField is used.
Instead of allowing for that, someone from Sun decides to demonstrate
horrible OO design (deprecating a method in a subclass that is public
and definitely not deprecated in the superclass) and take away a tool
that could prevent a conversion step in the normal case of an
application.
--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation