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 Max > On 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
