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

Baesken, Matthias matthias.baesken at sap.com
Thu Aug 9 07:07:45 UTC 2018


> Did we get to a conclusion on whether to have central infrastructure to
> read/parse the security property? As I recall, this one was originally
> proposed before the generalization of the networking solution. There are
> details related to trimming that would be better not to duplicate if
> possible.

Hi Alan / Chris ,

I am aware of  

https://bugs.openjdk.java.net/browse/JDK-8207846

where jdk.net.includeInExceptions   has been generalized to be used for other use cases than  exceptions in the networking area .
This  has been pushed in the meantine.

Could you point me to the other discussion, is there already a webrev posted for this ?

> 
> Also, I think one of my comments on the original patch is that we should
> get the style and line lengths a bit more consistent with the existing
> code (the patch added excessively long lines for example).
>

Sure I'll look into it !

Best regards, Matthias


> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Mittwoch, 8. August 2018 20:30
> To: Baesken, Matthias <matthias.baesken at sap.com>; Chris Hegarty
> <chris.hegarty at oracle.com>
> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Langer, Christoph
> <christoph.langer at sap.com>; OpenJDK Dev list <security-
> dev at openjdk.java.net>
> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> parsing of jar archives
> 
> On 07/08/2018 16:00, Baesken, Matthias wrote:
> > Ping ....  ��  , any reviews / comments ?
> Did we get to a conclusion on whether to have central infrastructure to
> read/parse the security property? As I recall, this one was originally
> proposed before the generalization of the networking solution. There are
> details related to trimming that would be better not to duplicate if
> possible.
> 
> Also, I think one of my comments on the original patch is that we should
> get the style and line lengths a bit more consistent with the existing
> code (the patch added excessively long lines for example).
> 
> -Alan.


More information about the core-libs-dev mailing list