> 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.bate...@oracle.com] > Sent: Dienstag, 17. Juli 2018 13:39 > To: Baesken, Matthias <matthias.baes...@sap.com>; core-libs- > d...@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
