RFR 8056174: New APIs for jar signing

[Wang Weijun]

> On Mar 28, 2015, at 04:30, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 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.

(Not really, the policy file format is not localized, why should its error msg be?)

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

Suppose someone writes a GUI tool as a wrapper of this API. It is not easy for it to understand all exception messages and localize them. Throwable has a getLocalizedMessage() method, I'll see if I can use it.

Actually, since this exception should always be generated inside JDK, shall I just remove all constructors from the public API? (Suppose there is an easy way to construct it without a public ctor). Is there such an example?

> 
>> 
>>> 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).

Great answer. I now think it should be unchecked.

Thanks
Max

> 
> Mandy
> 
>