RFR 8180573: Refactor sun/security/tools shell tests to plain java tests

[Philipp Kunz]

Hi Max,

I don't know if it is important enough, certainly not a serious issue.
In your patch, for example in DiffEnd.java and a few other tests,
Strings are encoded to byte streams with String.getBytes() which uses
the default platform character set to encode the strings.
Manifests, however, always use UTF-8 as the character set to encode. In
my opinion, getBytes(java.nio.charset.StandardCharsets.UTF_8) would be
appropriate to specify the encoding in a platform-independent way.
Now the manifests used in the tests use so few different characters
that this might not even make a real difference because the first
around 100 characters or so of most character sets are the same in most
encodings.
I suspect that the encoding might also have been platform-dependent in
at least some of the previous shell tests and therefore this aspect
might as well be addressed separately and is not strictly necessary to
just properly convert shell tests to java.

Regards,
Philipp


On Wed, 2019-02-13 at 11:01 +0800, Weijun Wang wrote:
> Please review the fix at
> 
>    https://cr.openjdk.java.net/~weijun/8180573/webrev.00/
> 
> Notes:
> 
> - Most changes are just .sh -> .java
> 
> - StorePasswordsByShell.sh combined into StorePasswords.java
> 
> - In most cases, JarUtils is called to create a jar file. Sometimes the jar command is called because of delicate differences, for example, jar adds directory entries also.
> 
> - The i18n tests are completely manual described in i18n.html. Old i18n.java is useless, now is also empty.
> 
> - Copyright year updated to 2019, @bug unchanged.
> 
> Two files not converted yet:
> 
> - ./keytool/console.sh
> 
> This is a manual test calling old versions of JDK.
> 
> - ./keytool/ListKeychainStore.sh
> 
> I tried on this one but "security list-keychains -s ..." has no effect on mach5 machines when calling by ProcessTools. No idea why, I've created a separate bug (JDK-8218886) for it.
> 
> Thanks,
> Max
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190215/4aa93c16/attachment.htm>