Thoughts on possible options to JDK-8027598

[Bradford Wetmore]

 > jtreg team? I am not aware of one. Jon Gibbons works on this in his
 > spare time.

I would call him "the JTREG team."

Was there an ETA for this?  Balancing recent test stabilization efforts 
with this, you may consider consider adding othervm and then back it out 
when the JTREG fix is made.

Brad



On 11/25/2013 2:29 AM, Chris Hegarty wrote:
> 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
>>>
>>