> 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
