The argument he is making is probably this:
- String in Java is immutable, and therefore, an in-memory secret represented as a String an cannot be destroyed.
- If you have secrets stored in memory, and that memory gets swapped to disk, another process on the same box can allocate large chunks of memory at random, and potentially look for passwords in the uninitialized memory they get back.
- If you store a password as char, you can do something like:
This will reduce the time the secret is stored in memory, and reduce the likelihood of exposing it through an unintended channel.
char  password = getPassword();
I don't know if this argument is still valid for modern OSs, but I have noticed that some of the java security APIs have moved aware from String in favor of char (the Keystore API for example). Also the swing components for reading password all use char now too.
For web applications, I'm not so sure it matters -- in a web server, you are usually always going to get the password from a form, so its going through the HTTP request, the servlet API and has already been converted to a String.
If your web server/servlet engine has some way of clearing out the memory used by the request when the servlet handing thread is done with it, then it would make sense to worry about your framework code not following the destroyable interface; but I sort of doubt that modern web containers actually do this.