Thoughts on possible options to JDK-8027598

[Sean Mullan]

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.

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.

--Sean