> 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.bate...@oracle.com> > Sent: Mittwoch, 8. August 2018 20:30 > To: Baesken, Matthias <matthias.baes...@sap.com>; Chris Hegarty > <chris.hega...@oracle.com> > Cc: core-libs-dev@openjdk.java.net; Lindenmaier, Goetz > <goetz.lindenma...@sap.com>; Langer, Christoph > <christoph.lan...@sap.com>; OpenJDK Dev list <security- > d...@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.
