RFR 8056174: New APIs for jar signing

[Mandy Chung]

On 3/26/15 9:18 PM, Wang Weijun wrote:
>>
>> JarSignerException.ErrorCode - do you expect the caller will want
>> to process error handling differently with different type of error?
>>
>> I wonder if the error message would be good enough wrapping the
>> Throwable cause.
> Yes, I agree a ctor with arguments (message, cause) is enough. The type of cause is actually equivalent to the ErrorCode. The new message argument should be localized.

Generally, JDK tool emitted messages are localized but exception messages
are not localized.  I notice that some security exception messages are
localized (sun/security/util/Resources.java and sun/security/util/AuthResources.java)
that may make sense for example parsing policy file.

I think the application using this API should be handling the localization
not in the exception message.

>
>> Should JarSignerException be an unchecked exception?
> In traditional Java style, it should be checked. Normally unchecked exception should not be expected if running normally, but here we will see TSA connection error, algorithm name error, etc.
>
> In fact I originally suggested unchecked exception, but my main reason is that a checked permission is not friendly with lambda and a little old fashioned.

This exception is thrown at error cases. It looks like when the
exception is raised, there is no action the caller can do other
than outputting an error message and exit, right?  Then
unchecked exception would be more appropriate (see Effective Java
item 59).

Mandy