Looks good. --Sean
On 12/7/17 9:39 AM, Weijun Wang wrote:
I think my previous fix introduced a behavior change. Here is an update: http://cr.openjdk.java.net/~weijun/8192987/webrev.01/ Precisely, the "hasStoretypeOption == false" is equivalent to "storetype == null" but should not be removed. Although we can probe storetype of pkcs12/jks/jceks, that doesn't mean we can probe a 3rd party storetype. The test is updated so that when a wrong storetype is provided, it will be used and the loading of keystore would fail. Thanks MaxOn Dec 7, 2017, at 9:06 PM, Sean Mullan <sean.mul...@oracle.com> wrote: Update the copyright date on KeyStoreUtil.java. Otherwise looks fine to me. --Sean On 12/7/17 3:53 AM, Weijun Wang wrote:Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8192987/webrev.00/ The fix delays the assignment of storetype and srcstoretype (when they are not provided on the command line) to where the actual keystore file is loaded. I could have retained lines 711-719 because we had hasStoretypeOption and hasSrcStoretypeOption flags indicating whether they are provided by the user or set on those lines, but leaving them to be null as long as possible helps exposing any unintended usages. Now they are only used in pkcs11 and MSCAPI type checks which are null safe, and hasStoretypeOption and hasSrcStoretypeOption are now useless and removed. Thanks Max
