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

[Jaikiran Pai]

I agree with Chris. Unlike the connection failure error messages where
the IP/port being part of the error message did add value, I don't think
including the "path" to the jar (something like
/opt/private/foo/bar/helloworld.jar) in case of MANIFEST parsing errors
is really necessary. I think, just the filename (helloworld.jar) and the
line number should be good enough in such failures. I have been trying
to think in what cases the entire path would be necessary, to understand
what's causing the parsing failure and address the issue. So far, I
haven't been able to come up with such a use case.

I do understand, as Alan already noted in this thread, the ZipFile APIs
accept a file "path". So, directly using those paths in the error
messages won't work out. Perhaps this changeset can be changed to do the
necessary work to just get hold of the file name (while constructing the
error message)? That way it wouldn't need any of these security
configurations?

-Jaikiran

On 19/07/18 3:37 PM, Chris Hegarty wrote:
>> On 19 Jul 2018, at 09:07, Baesken, Matthias
>> <matthias.baesken at sap.com> wrote: Hello, in the meantime I prepared a
>> CSR : https://bugs.openjdk.java.net/browse/JDK-8207768 
> 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 at oracle.com] Sent: Mittwoch, 18. Juli 2018 19:44
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; core-libs-
>>> dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at 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 
>