[RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

Baesken, Matthias matthias.baesken at sap.com
Wed Jul 18 08:21:33 UTC 2018


> The name of the security/system property will need discussion as
> "jdk.includeInExceptions" is very general. If we have something general
> then we'll need a good name and replace the existing
> jdk.net.includeInExceptions. It might be better to go with something
> specific for the area such as "jdk.util.jar.includeInExceptions=jarpath"
> (to be consistent with other jdk.* properties in this code). A CSR will
> be needed for this too as the property will be documented in the
> java.security file.

Hi Alan,  I'll prepare a CSR .
I selected a  more general name  "jdk.includeInExceptions"  ,  because there is the idea to enhance more exceptions  with additional output .
In such a case " jdk.util.jar.includeInExceptions"   would not really help .
However so far it is still a bit unclear how many exceptions we would like to enhance , so this has to be checked first .

Best regards, Matthias


> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> Sent: Dienstag, 17. Juli 2018 13:39
> To: Baesken, Matthias <matthias.baesken at sap.com>; core-libs-
> dev at openjdk.java.net
> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> parsing of jar archives
> 
> On 16/07/2018 14:53, Baesken, Matthias wrote:
> > Hello,  after latest  comments  from Alan  and Jaikiran    I created a new
> webrev :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.2/
> >
> > The  jar file path is  now printed  in case   jdk.includeInExceptions   contains
> jarpath     (this approach   is "borrowed"   from the enhanced socket
> exceptions ) .
> > The line number is always printed .
> >
> The general approach seems okay and consistent with the agreement on
> how
> to reveal host names in socket exceptions.
> 
> The name of the security/system property will need discussion as
> "jdk.includeInExceptions" is very general. If we have something general
> then we'll need a good name and replace the existing
> jdk.net.includeInExceptions. It might be better to go with something
> specific for the area such as "jdk.util.jar.includeInExceptions=jarpath"
> (to be consistent with other jdk.* properties in this code). A CSR will
> be needed for this too as the property will be documented in the
> java.security file.
> 
> As regards the patch then it mostly looks okay but I think the changes
> in Attributes will need cleanup to get it consistent (esp. the line
> lengths) with the existing code.
> 
> -Alan



More information about the core-libs-dev mailing list