On 02/10/2012 03:57, Stephen Flores wrote:
:
Alan,
I am going to take you advice and push back on feature creep, I need
to stick plan we agreed to and that I put in the CR, so I can move
back to complete sun.security.ec decoupling work and I don't think
this change makes it harder for me to move resources or a waste of
time later. I think cleaning up modularity when you can is a good thing.
I'm okay with this.
:
I agree with Max's question about whether you need to leave a
sun.security.tools.KeyTool in case anyone invokes it directly (no one
should be dependent on sun.security.** classes of course but still
working considering).
I got the impression from you that we would add the later.
Max is away at the moment. I think we had a small concern that Glassfish
and others may be using sun.security.tools.KeyTool directly, although I
think Max checked it and said this was no longer the case. A forwarding
class can be trivially added later if needed.
In sun/security/tools/KeyStoreUtil.java then maybe getPassWithModifier
can use try-with-resources.
I don't understand what you mean by "try-with-resources", I don't
think JarSigner should rely on KeyTool resources, so I copied the 3
resources it needed from keytool to jarsigner. I feel that even though
for time reasons we did not put the other tools in their own JARs, to
code should not preclude that in the future.
I wasn't clear, I meant try-with-resources, the language feature.
You're using it already at line 97 of the test, I was just suggesting
that you could use it at line 133 too and that will ensure that the
stream is closed, even if the readLine fails.
Is the change to sun/security/tools/keytool/autotest.sh just a merge
issue?
When I ran jprt I got the very confusing "Cannot find LIBNAME"
message, libsoftokn3.so, so I just wanted tester's in the future to
have correct message.
OK.
-Alan.
