Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[JDK18] System.setSecurityManager didn't throw UnsupportedOperationException #14092

Closed
babsingh opened this issue Dec 6, 2021 · 1 comment · Fixed by #14329
Closed

[JDK18] System.setSecurityManager didn't throw UnsupportedOperationException #14092

babsingh opened this issue Dec 6, 2021 · 1 comment · Fixed by #14329
Assignees
@babsingh
Labels
comp:vm jdk18
Milestone
Release 0.31 (Jav...

Comments

@babsingh
Copy link
Contributor

babsingh commented Dec 6, 2021

OpenJDK Tests

TEST: java/lang/System/AllowSecurityManager.java

Errors

[2021-11-17T18:34:44.360Z] WARNING: A terminally deprecated method in java.lang.System has been called
[2021-11-17T18:34:44.360Z] WARNING: System::setSecurityManager has been called by AllowSecurityManager (file:/home/jenkins/workspace/Test_openjdknext_j9_sanity.openjdk_aarch64_linux_OpenJDK/aqa-tests/TKG/output_16371734171260/jdk_lan
g_0/work/classes/0/java/lang/System/AllowSecurityManager.d/)
[2021-11-17T18:34:44.360Z] WARNING: Please consider reporting this to the maintainers of AllowSecurityManager
[2021-11-17T18:34:44.360Z] WARNING: System::setSecurityManager will be removed in a future release
[2021-11-17T18:34:44.360Z] java.lang.Exception: System.setSecurityManager did not throw UnsupportedOperationException
[2021-11-17T18:34:44.360Z]      at AllowSecurityManager.main(AllowSecurityManager.java:42)
[2021-11-17T18:34:44.360Z]      at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[2021-11-17T18:34:44.360Z]      at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
[2021-11-17T18:34:44.360Z]      at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:52)
[2021-11-17T18:34:44.360Z]      at java.base/java.lang.reflect.Method.invoke(Method.java:577)
[2021-11-17T18:34:44.360Z]      at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
[2021-11-17T18:34:44.360Z]      at java.base/java.lang.Thread.run(Thread.java:884)

Related: #13946
@babsingh babsingh added this to the Release 0.31 (Java 18) milestone Dec 6, 2021
babsingh added a commit to babsingh/aqa-tests that referenced this issue Dec 6, 2021
@babsingh
Update JDK18 test exclusion list
803a419 
eclipse-openj9/openj9#13995 has been fixed via eclipse-openj9/openj9#14044.
So, the tests excluded for eclipse-openj9/openj9#13995 have been re-enabled.

Tests failures documented in the below issues have been excluded:
- eclipse-openj9/openj9#14079
- eclipse-openj9/openj9#14080
- eclipse-openj9/openj9#14084
- eclipse-openj9/openj9#14091
- eclipse-openj9/openj9#14092
- eclipse-openj9/openj9#14093
- eclipse-openj9/openj9#14094
- eclipse-openj9/openj9#14095

Signed-off-by: Babneet Singh <[email protected]>
This was referenced Dec 6, 2021
Merged
Closed
babsingh added a commit to babsingh/aqa-tests that referenced this issue Dec 6, 2021
@babsingh
Update JDK18 test exclusion list
b44282d 
eclipse-openj9/openj9#13995 has been fixed via eclipse-openj9/openj9#14044.
So, the tests excluded for eclipse-openj9/openj9#13995 have been re-enabled.

Test failures documented in the below issues have been excluded:
- eclipse-openj9/openj9#14079
- eclipse-openj9/openj9#14080
- eclipse-openj9/openj9#14084
- eclipse-openj9/openj9#14091
- eclipse-openj9/openj9#14092
- eclipse-openj9/openj9#14093
- eclipse-openj9/openj9#14094
- eclipse-openj9/openj9#14095

Signed-off-by: Babneet Singh <[email protected]>
llxia pushed a commit to adoptium/aqa-tests that referenced this issue Dec 7, 2021
@babsingh
Update JDK18 test exclusion list (#3164)
a955d13 
eclipse-openj9/openj9#13995 has been fixed via eclipse-openj9/openj9#14044.
So, the tests excluded for eclipse-openj9/openj9#13995 have been re-enabled.

Test failures documented in the below issues have been excluded:
- eclipse-openj9/openj9#14079
- eclipse-openj9/openj9#14080
- eclipse-openj9/openj9#14084
- eclipse-openj9/openj9#14091
- eclipse-openj9/openj9#14092
- eclipse-openj9/openj9#14093
- eclipse-openj9/openj9#14094
- eclipse-openj9/openj9#14095

Signed-off-by: Babneet Singh <[email protected]>
@babsingh babsingh self-assigned this Jan 17, 2022
@babsingh babsingh mentioned this issue Jan 20, 2022
Merged
babsingh added a commit to babsingh/openj9 that referenced this issue Feb 3, 2022
@babsingh
Update java.security.manager behaviour
075f02d 
1. Consolidate security manager startup code invoked from
ClassLoader.initializeClassLoaders in System.initSecurityManager (new method).

2. As per the Java doc, the java.security.manager property should only be read
at startup. Example: If this property is initialized with "disallow" when the
JVM is started, then a security manager will not be set at startup and cannot
be set dynamically. Currently, this property is read in
System.setSecurityManager. If a user changes this property after startup, then
System.setSecurityManager's behaviour will change after startup. This behaviour
does not follow the Java doc and reference implementation. To fix this issue,
the java.security.manager is only read once at startup in
System.initSecurityManager.

3. In JDK18, System.setSecurityManager's run-time behaviour changes with
respect to the java.security.manager property. Previously, if the property
was null, the run-time behaviour was success or throws SecurityException.
In JDK18, the new behaviour is to throw UnsupportedOperationException if the
property is null. This matches the behaviour when the property is set to
"disallow".

Fixes: eclipse-openj9#14092
Fixes: eclipse-openj9#14094

Signed-off-by: Babneet Singh <[email protected]>
babsingh added a commit to babsingh/openj9 that referenced this issue Feb 4, 2022
@babsingh
Update java.security.manager behaviour
a03e350 
1. Consolidate security manager startup code invoked from
ClassLoader.initializeClassLoaders in System.initSecurityManager (new method).

2. As per the Java doc, the java.security.manager property should only be read
at startup. Example: If this property is initialized with "disallow" when the
JVM is started, then a security manager will not be set at startup and cannot
be set dynamically. Currently, this property is read in
System.setSecurityManager. If a user changes this property after startup, then
System.setSecurityManager's behaviour will change after startup. This behaviour
does not follow the Java doc and reference implementation. To fix this issue,
the java.security.manager is only read once at startup in
System.initSecurityManager.

3. In JDK18, System.setSecurityManager's run-time behaviour changes with
respect to the java.security.manager property. Previously, if the property
was null, the run-time behaviour was success or throws SecurityException.
In JDK18, the new behaviour is to throw UnsupportedOperationException if the
property is null. This matches the behaviour when the property is set to
"disallow".

Fixes: eclipse-openj9#14092
Fixes: eclipse-openj9#14094

Signed-off-by: Babneet Singh <[email protected]>
@babsingh babsingh mentioned this issue Feb 4, 2022
Merged
@babsingh
Copy link
Contributor Author

babsingh commented Feb 4, 2022

Test re-enabled via adoptium/aqa-tests#3318.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@babsingh babsingh

Labels
comp:vm jdk18
Projects
None yet
Milestone
Release 0.31 (Java 18)
Development

Successfully merging a pull request may close this issue.

Update java.security.manager behaviour babsingh/openj9
1 participant
@babsingh