Hi Arthur,
On 07/05/2019 19:35, Arthur Eubanks wrote:
When you said "double checking" I thought it was some terminology
related to security managers (e.g. "double checked locking") :P
Oh - sorry I was not clear enough.
I looked through all the tests I modified for any references to security
managers or policy files (grep "security" and "policy"). There is
one, test/jdk/java/net/InetAddress/GetLocalHostWithSM.java, but the call
to IPSupport is before the test sets the SecurityManager.
So the existing tests should not be affected by this.
Thanks :-) That's what I wanted to hear.
With help from Chris's references ([1]), I added a test with a policy
file that grants IPSupport permission to listen/resolve localhost:0, and
read the java.net.preferIPv4Stack system property. Without either
permission, the test fails as expected.
One thing I discovered is that to make the policy file work properly
with the jtreg directory structure, I needed to add "@build
jdk.test.lib.net.IPSupport" to the test. So any test that wants to use
IPSupport and security managers needs to have that extra line and make
sure that its policy file contains all the permissions as in the new
test policy I added.
Without "@build jdk.test.lib.net.IPSupport", the policy file would need
grant codeBase "file:${test.classes}/-"
With "@build jdk.test.lib.net.IPSupport", the policy file needs grant
codeBase "file:${test.classes}/../../../../test/lib/-"
This matches [1], and seems more restrictive (only applies to test
library code) and better.
Ah! yes - there's this old (odd?) behavior about where jtreg
generates the library test classes. That has bitten us in the
past - mostly because if you start using using @build then
the test must explicitly list all classes it intends to use.
Otherwise, some test might pass 'by chance' because some
other test has run before and caused jtreg to compile the
classes it needs. The classic symptom would be that the test passes
when you run :jdk_net but fail when you run it in isolation
(when it's the only test that your jtreg command line compiles).
So if you add @build jdk.test.lib.net.IPSupport then please
make sure to add all the library classes that the test might
be using on the @build command line (IIRC wildcards are also
accepted). Just mentioning it for the future as I see these
changes shouldn't have this issue.
New webrev: http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/
http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/test/jdk/java/net/MulticastSocket/JoinLeave.java.frames.html
has two `@library /test/lib` lines
The rest looks very good to me!
Thanks for taking that on, and thanks for adding the new test!
best regards,
-- daniel
[1]:
https://hg.openjdk.java.net/jdk/jdk/file/1dc9bf9d016b/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24
