Thoughts on possible options to JDK-8027598

[Chris Hegarty]

On 22/11/13 21:11, Rajan Halade wrote:
>
> On 11/22/2013 11:42, Sean Mullan wrote:
>> On 11/21/2013 04:53 AM, Chris Hegarty wrote:
>>>>>> If I am correct, JTREG has support provider cleanup already. But the
>>>>>> question is even JTREG reset the providers, it still cannot ensure
>>>>>> next
>>>>>> test won't be impacted because in some circumstances JDK may need to
>>>>>> cache something which depends on previous providers. Still need to
>>>>>> analysis the test case by case.
>>>>>
>>>>> Right, any static or cached data may be invalid, and this will require
>>>>> careful changes to the JRE itself.
>>>> Pardon my ignorance - if I gather correctly then ProvidersSnapshot
>>>> library also doesn't sandbox effects completely.
>>>
>>> FYI. I am not part of the security team, and someone from the security
>>> group should ultimately have to agree/disagree, but we have similar
>>> issues in other parts of the platform. I don't know the specifics of the
>>> code here so it may, or may not, be an issue.
>>>
>>> If any part of the security framework stores values in static fields,
>>> that is dependent on the security providers, then when the providers
>>> change this static value may be incorrect.
>>>
>>> We encounter this from time to time with system properties. E.g. JDK
>>> HTTP Client code reads system property and stores in static field, JDK
>>> HTTP Client will never never re-read the property as it believes it will
>>> not change. Having jtreg reset/clean certain system properties will not
>>> help in this case.
>>
>> Yes, the example with system properties is a good one.
>>
>> However, providers are designed to be added and removed dynamically
>> (see the java.security.Security API), so if there is some static
>> information not being cleared when providers are reset, I would tend
>> to think it may be a bug in the JDK.

OK, if this is the case then that is fine.

> yes. thanks!
>>
>> My preference would be change jtreg to clear/restore providers, and
>> more thoroughly analyze any subsequent test failures as it may be a
>> bug in the JDK.
> Ok, I will follow up with jtreg team to find out when they can commit to
> timeline.

jtreg team? I am not aware of one. Jon Gibbons works on this in his 
spare time.  You may want to take a look at jtreg [1] in the code tools 
project.

-Chris.

[1] http://openjdk.java.net/projects/code-tools/jtreg/

>
> - Rajan
>>
>> --Sean
>>
>