8268349: Provide more detail in JEP 411 warning messages #4400
Conversation
|
|
|
/label add security |
|
/csr needed |
|
@wangweij |
|
@wangweij has indicated that a compatibility and specification (CSR) request is needed for this pull request. |
| WARNING: A Security Manager implementation has been enabled on the command line | ||
| WARNING: java.lang.SecurityManager is deprecated and will be removed in a future release | ||
| WARNING: -Djava.security.manager=%s will have no effect when java.lang.SecurityManager is removed | ||
| """, smProp); |
There was a problem hiding this comment.
Raw strings may be useful here but means the lines length are inconsistent and makes it too hard to look at side by side diffs now.
There was a problem hiding this comment.
I understand what you mean when I switch to Split View. While I can extract the lines to a method, I somehow think it's not worth doing because for each type of warning the method is only called once.
| @@ -324,6 +327,22 @@ private static void checkIO() { | |||
| private static native void setOut0(PrintStream out); | |||
| private static native void setErr0(PrintStream err); | |||
|
|
|||
| // Remember original System.err. setSecurityManager() warning goes here | |||
| private static PrintStream oldErrStream = null; | |||
There was a problem hiding this comment.
I assume this should needs to be volatile and @stable. I think we need a better name for it too.
There was a problem hiding this comment.
Will add the modifiers. How about "originalErr"?
| private static class CallerHolder { | ||
| // Remember callers of setSecurityManager() here so that warning | ||
| // is only printed once for each different caller | ||
| final static Map<String, Boolean> callersOfSSM = new WeakHashMap<>(); |
There was a problem hiding this comment.
You can't use a WeakHashMap without synchronization but a big question here is whether a single caller frame is sufficient. If I were doing this then I think I would capture the hash of a number of stack frames to create a better filter.
There was a problem hiding this comment.
I thought about that but not sure of performance impact. Is the worst problem that more than one warnings will be printed for a single caller? It's not really harmless.
As for the frame, if the warning message only contain the caller class name and its code source, why is it worth using a key of multiple frames? The message will look the same.
There was a problem hiding this comment.
I thought about that but not sure of performance impact. Is the worst problem that more than one warnings will be printed for a single caller? It's not really harmless.
As for the frame, if the warning message only contain the caller class name and its code source, why is it worth using a key of multiple frames? The message will look the same.
WeakHashMap access needs synchronization. Whether we need to cache to avoid excessive warnings isn't clear. If the SM is enabled once and never disabled/re-enabled then caching isn't interesting. On the other hand if there are programs that are enabling/disabling to execute subsets of code then maybe it is. Maybe we should just drop this and see if there is any feedback on the repeated warning?
There was a problem hiding this comment.
Not sure what you meant by "WeakHashMap access synchronization", it's just a noun without any other parts. Do you think synchronization is necessary?
For the cache, I'm OK to drop it at the moment.
There was a problem hiding this comment.
I think it would be simpler to start out without the caller cache. Sorry the sentence got garbled, I was trying to repeat what I said above that WeakHashMap is not synchronized so you would need to add synchronization to use it.
There was a problem hiding this comment.
There are a number of hotspot tests that will trigger this warning, so please ensure they work correctly with the extra output.
You might want to make your "WARNING" consistent with the VM's "Warning" so that OutputAnalyzer's logic to ignore warnings will automatically ignore these too.
Thanks,
David
The uppercase "WARNING" is intentional here, it was the same with illegal reflective access warnings. I'm sure Max has or will run all tests to see if there are any issues. |
|
Changes to LoggerFinderLoaderTest look reasonable to me. |
Will definitely run all from tier1-tier9. I ran them multiple times while implementing JEP 411. I've seen warnings with "VM" word in the prefix and test methods that filter them out, but feel the warnings here are not related to VM. The new warnings do have impacts on some tests and I'll be very carefully not break them. |
|
Mailing list message from Peter Firmstone on security-dev: I can re-license some code that decorates Concurrent collections with https://pfirmstone.github.io/JGDMS/jgdms-collections/apidocs/index.html On 9/06/2021 4:31 am, Alan Bateman wrote: -- Peter Firmstone |
1 similar comment
|
Mailing list message from Peter Firmstone on security-dev: I can re-license some code that decorates Concurrent collections with https://pfirmstone.github.io/JGDMS/jgdms-collections/apidocs/index.html On 9/06/2021 4:31 am, Alan Bateman wrote: -- Peter Firmstone |
More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime.
Progress
Integration blocker
Issue
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4400/head:pull/4400$ git checkout pull/4400Update a local copy of the PR:
$ git checkout pull/4400$ git pull https://git.openjdk.java.net/jdk pull/4400/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 4400View PR using the GUI difftool:
$ git pr show -t 4400Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4400.diff