On 19 Jul 2018, at 09:07, Baesken, Matthias <matthias.baesken@sap.com> wrote:
Hello, in the meantime I prepared a CSR :
This CSR seems a little premature. Matthias said: "However so far it is still a bit unclear how many exceptions we would like to enhance , so this has to be checked first “. Has this been checked? I have seen no update on this or any other email thread. JDK-8204233 [1] was a pragmatic and targeted solution to a long standing complaint. It was not intended, as is obvious by the newly added property name, to set precedent for doing similar all over the platform. If, after a broader discussion, this approach is to be applied to several different areas of the platform, then maybe JDK-8204233 should be revisited ( noting that it is JDK 11, which is currently in RDP 1 ). I think we should try to avoid a whole plethora of these properties. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8204233
jdk.includeInExceptions expands the scope. That might be okay but we will need to re-visit jdk.net.includeInExceptions and also move the support to somewhere in jdk.internal so that it can be used by other code in java.base.
Is there some support code for " jdk.net.includeInExceptions " or do you just mean the name of the property ?
Best regards, Matthias
-----Original Message----- From: Alan Bateman [mailto:Alan.Bateman@oracle.com] Sent: Mittwoch, 18. Juli 2018 19:44 To: Baesken, Matthias <matthias.baesken@sap.com>; core-libs- dev@openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier@sap.com> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives
On 18/07/2018 09:21, Baesken, Matthias wrote:
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 .
jdk.includeInExceptions expands the scope. That might be okay but we will need to re-visit jdk.net.includeInExceptions and also move the support to somewhere in jdk.internal so that it can be used by other code in java.base.
-Alan