Hi Sean Do you have other comments on the webrev [1]?
I've also updated the CSR [2]. Thanks Max [1] http://cr.openjdk.java.net/~weijun/8014628/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8193851 > On Jan 13, 2018, at 3:52 AM, Sean Mullan <sean.mul...@oracle.com> wrote: > > On 1/9/18 8:40 PM, Weijun Wang wrote: >>> The code can also throw GeneralSecurityException but those are also always >>> suppressed because of the catch block. Is that the right behavior? >>> >> Not a right behavior but should be harmless here. In my understanding, in >> the case of PBE, as long the passphrase, salt, iteration count etc are >> legal, there will be no further problem in generating a key, choosing a >> cipher, and do the encryption work, unless there is a programming error. >> I think the original designer (of other etypes) meant to let >> stringToKey(char,String,byte[]) returning a null when there is an error, and >> all callers of this method will deal with null instead of an exception. If >> not programmed carefully, this might turn a GeneralSecurityException to a >> NullPointerException. > > Ok, I think this is bad practice, but since it has worked that way since the > beginning, I'm ok with leaving it alone. > > --Sean
