[RFR] 8205525 : Improve exception messages during manifest parsing of jar archives
Sean Mullan
sean.mullan at oracle.com
Thu Jul 19 14:42:49 UTC 2018
On 7/19/18 8:54 AM, Chris Hegarty wrote:
>
>> On 19 Jul 2018, at 11:46, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>> On 19/07/2018 09:07, Baesken, Matthias wrote:
>>> Hello, in the meantime I prepared a CSR :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8207768
>>>
>>>
>>>> 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 ?
>>>
>> Chris is right that it's a bit premature to submit a CSR while the question on whether to rename the existing security property is on the table. I have no objection to doing that.
>
> I filed the following issue to generalize the `includeInExceptions` security
> property:
> https://bugs.openjdk.java.net/browse/JDK-8207846
>
> I would like to resolve 8207846 first, then 8205525 can propose to add the
> new argument value, `jarPath`.
Note that making this a security property for all general cases may have
performance implications in certain scenarios since the java.security
file will need to be loaded and fully parsed before it can be used. If
you are already parsing the java.security file for something else (which
is probably the case for jdk.net.includeInExceptions), then it should be
fine, but that may not always be the case if this is made into a more
general property. Just something to think about ...
--Sean
More information about the core-libs-dev
mailing list