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.

AFAIK, it's not actually possible to do on all OSes -- at least the crypto
people seem fairly sure that there's no defined way of doing it (that actually
/works/) on Windows.

Not to say that JPasswordField, if used as Chris describes, isn't a reasonable
solution for a given application.

Actually, looking at the code, I'm not too impressed.  In terms of sofware
engineering, it inherits from JTextField and (therefore) uses Document --
complex classes that have no security responsibilities themeselves and which
are therefore fragile if used in a secure context.  In terms of functionality,
there is no need to keep the password text "in plain" in memory at all, and
there should be an API for retrieving it without assembling it into a String or
char[].  You can't get security against an attacker who is able to review /all/
the contents of memory, but you can certainly -- and quite easily -- make the
job of a would-be attacker using a partial memory trace (say from the "swap"
file), and lacking the resources of a major governement, much harder or even
(perhaps) impossible.  Of course, for that level of protection to make sense,
there must also be a way to /use/ the password which doesn't require assembling
it into plaintext in memory, and (afaik) such APIs don't commonly exist, and
for some purposes may not even be possible.

   -- chris