Hello, i am hated at work to introduce char[] parameters for passwords, and after having a few years of experience with it I can say they are hardly worth it: Most often the caller has strings to work with anyway and need to copy them to char Array or the called Code Works with strings, or it is hard for the caller and callee to agree when to zero the Content. And if You Look closely with all generational collectors a string object typically survives not even the first eden copy (typically seconds).
having Said that, it might be good to consider CharSequence in future APIs. Bernd -- http://bernd.eckenfels.net ----- Ursprüngliche Nachricht ----- Von: "Nicholas Castorina" <nicholas.castor...@openmarket.com> Gesendet: 05.11.2014 19:01 An: "user@commons.apache.org" <user@commons.apache.org> Betreff: [FTP and FTPS] using char[] password instead of String Howdy, Is there a way to use the FTPSClient.login(username, password) where password is a char[] instead of a String? Strings are immutable and don't get removed from memory until garbage collection. That means that the password can possibly be recovered from a memory dump. However, if password was a char[], I could do Arrays.fill(password, ' ') and there would be no traces of the password in memory once I was done with using it. For a more detailed explanation of this, you can go to http://stackoverflow.com/questions/8881291/why-is-char-preferred-over-string-for-passwords. I didn't see an option for a char[] instead of String for password, but I could have missed one. If there is not currently a way to use a char[], you could also probably get away with changing the password from type String to CharSequence (the interface that String implements). That way FTPSClient is backwards compatible and you can clear passwords after use by using a CharBuffer (also implements CharSequence) instead of a String. Thanks, Nicholas Castorina This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
