[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