On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls wrote:
>> Deprecate the Java Management Extension (JMX) Management Applet (m-let)
>> feature for removal.
>>
>> This deprecation will have no impact on users of other JMX features, the
>> JDK's built-in instrumentation, or any of the observability
On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo wrote:
> Please review this superficial documentation cleanup that was triggered by
> unrelated analysis of doc comments in JDK API.
>
> The only effect that this multi-area PR has on the JDK API Documentation
> (i.e. the observable effect on the ge
On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona wrote:
> Most of the manpages were updated a few years ago but some references remain.
> This patch renames remaining references to "macOS".
>
> Please review.
>
> Thanks,
> Adam
keytool and jarsigner docs look good.
-
Marked as review
On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang wrote:
> Add null-checks in all `LoginModule` implementations. It's possible that an
> application calls `logout` after a login failure, where most internal
> variables for principals and credentials are null and removing a null from
> the `Subject`
On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang wrote:
> Add null-checks in all `LoginModule` implementations. It's possible that an
> application calls `logout` after a login failure, where most internal
> variables for principals and credentials are null and removing a null from
> the `Subject`
On Mon, 11 Jul 2022 19:49:13 GMT, Weijun Wang wrote:
>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java
>> line 289:
>>
>>> 287: subject.getPrincipals().remove(GIDPrincipal);
>>> 288: }
>>> 289: if (supplementaryGroups != null) {
On Mon, 11 Jul 2022 21:03:16 GMT, Weijun Wang wrote:
>> test/jdk/javax/security/auth/login/modules/SafeLogout.java line 51:
>>
>>> 49:
>>> 50: static void test(int pos) throws Exception {
>>> 51: // Create random JAAS login config.
>>
>> I'm probably missing something obvious, but
On Tue, 12 Jul 2022 17:38:38 GMT, Weijun Wang wrote:
>> Why isn't it sufficient to just call logout once per each login module?
>
> I meant to make the test more real. When there are multiple login modules,
> the principals and credentials sets could be different. For example, the
> `privateCre
On Sat, 16 Jul 2022 13:46:58 GMT, Weijun Wang wrote:
>> Add null-checks in all `LoginModule` implementations. It's possible that an
>> application calls `logout` after a login failure, where most internal
>> variables for principals and credentials are null and removing a null from
>> the `Sub
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (199
On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote:
>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
>> removal, and remove the remaining special handling of ThreadDeath from the
>> JDK.
>>
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.
On Fri, 16 Sep 2022 09:45:14 GMT, Alan Bateman wrote:
>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
>> removal, and remove the remaining special handling of ThreadDeath from the
>> JDK.
>>
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.
On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman wrote:
> This is a test only change to remove the granting of
> RuntimePermission("stopThread") from the tests. With Thread.stop changed to
> throw UOE it means there is nothing that requires this permission.
Marked as reviewed by mullan (Reviewer)
On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman wrote:
> When referencing an RFC, it might be good to keep the RFC number in the text
> link.
+1.
-
PR: https://git.openjdk.org/jdk/pull/11073
On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject d
On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject d
On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject d
On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject d
On Mon, 4 Mar 2024 19:51:38 GMT, Weijun Wang wrote:
>> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java
>> line 309:
>>
>>> 307: final Subject s;
>>> 308: if (!SharedSecrets.getJavaLangAccess().allowSecurityManager())
>>> {
>>>
On Wed, 6 Mar 2024 11:46:16 GMT, Kevin Walls wrote:
>> The deprecated Subject Delegation feature in JMX will be removed.
>>
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the las
On Wed, 6 Mar 2024 11:46:16 GMT, Kevin Walls wrote:
>> The deprecated Subject Delegation feature in JMX will be removed.
>>
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the las
On Wed, 6 Mar 2024 11:46:16 GMT, Kevin Walls wrote:
>> The deprecated Subject Delegation feature in JMX will be removed.
>>
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the las
On Mon, 11 Mar 2024 15:19:08 GMT, Daniel Fuchs wrote:
> > Is there any value in keeping `SubjectDelegationPermission` after this
> > change? If so, I would mark that API deprecated for removal, so that it can
> > be removed in the next release or two.
>
> No issue with deprecation. I guess it
On Tue, 5 Mar 2024 19:56:58 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject di
On Tue, 5 Mar 2024 19:56:58 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject di
On Wed, 20 Mar 2024 14:45:50 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject d
On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang wrote:
>> This task addresses an essential aspect of our testing infrastructure: the
>> proper handling and cleanup of temporary files and socket files created
>> during test execution. The motivation behind these changes is to prevent the
>> accumu
On Thu, 16 May 2024 11:46:30 GMT, Kevin Walls wrote:
>> Running JConsole from a previous JDK, and attaching to jdk-23 (after
>> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): Remove the Java
>> Management Extension (JMX) Subject Delegation feature), the MBean tab is
>> blank.
>>
On Mon, 10 Jun 2024 16:52:26 GMT, Kevin Walls wrote:
>> JMX uses APIs related to the Security Mananger which are deprecated. Use of
>> AccessControlContext will be removed when Security Manager is removed.
>>
>> Until then, updates are needed to not require setting
>> -Djava.security.manager
On Tue, 11 Jun 2024 16:51:11 GMT, Weijun Wang wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Sean comments
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
> line 1436:
On Tue, 11 Jun 2024 19:35:18 GMT, Alan Bateman wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove annotations
>
> src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java line 84:
>
>> 82:
>> 83: Syst
On Tue, 11 Jun 2024 21:05:43 GMT, Sean Mullan wrote:
>> src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java line 84:
>>
>>> 82:
>>> 83: System.err.println("Warning: jstatd is deprecated for removal
>>> in a future release.");
&g
On Wed, 12 Jun 2024 16:11:28 GMT, Kevin Walls wrote:
>> JMX uses APIs related to the Security Mananger which are deprecated. Use of
>> AccessControlContext will be removed when Security Manager is removed.
>>
>> Until then, updates are needed to not require setting
>> -Djava.security.manager
On Wed, 12 Jun 2024 14:06:39 GMT, Kevin Walls wrote:
>> For the same reason you should be able to just call `Subject.current` in the
>> tests. I don't think you need the `SimpleStandard.useGetSubjectACC` property
>> to toggle the testing of either old or replacement APIs as long as the test
>>
On Mon, 17 Jun 2024 15:59:37 GMT, Kevin Walls wrote:
>> JMX uses APIs related to the Security Mananger which are deprecated. Use of
>> AccessControlContext will be removed when Security Manager is removed.
>>
>> Until then, updates are needed to not require setting
>> -Djava.security.manager
On Mon, 17 Jun 2024 15:53:19 GMT, Kevin Walls wrote:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>> line 1314:
>>
>>> 1312: return AccessController.doPrivileged(action, acc);
>>> 1313: }
>>> 1314: }
On Mon, 17 Jun 2024 15:59:37 GMT, Kevin Walls wrote:
>> JMX uses APIs related to the Security Mananger which are deprecated. Use of
>> AccessControlContext will be removed when Security Manager is removed.
>>
>> Until then, updates are needed to not require setting
>> -Djava.security.manager
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start when compiling using
>>
On Tue, 15 Oct 2024 15:52:13 GMT, David M. Lloyd wrote:
>> OK
>
> While I disagree with this change on the principle of "the system should
> operate as if no security manager were installed", the workaround for callers
> is actually rather simple:
>
>
> if (System.getSecurityManager() != null
This is the implementation of JEP 486: Permanently Disable the Security
Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
[CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main
changes in the JEP and also includes an apidiff of the specification
On Tue, 15 Oct 2024 16:34:06 GMT, David M. Lloyd wrote:
>> While making `LogManager.checkAccess` be a no-op might be more convenient,
>> it could unconditionally
>> permit operations that formerly required a permission check: clearly a bad
>> idea. Always throwing a `SecurityException` is the s
ager enabled. After we integrate this JEP,
> those calls will be removed in each area (client-libs, core-libs, security,
> etc).
>
> I don't expect each reviewer to review all the code changes in this JEP.
> Rather, I advise that you only focus on the changes for the area
>
On Tue, 15 Oct 2024 22:14:00 GMT, Sean Mullan wrote:
>> src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java
>> line 225:
>>
>>> 223: */
>>> 224: public static JMXConnector connect(JMXServiceURL serviceURL)
>
On Tue, 15 Oct 2024 17:01:59 GMT, Sean Mullan wrote:
>>> While making `LogManager.checkAccess` be a no-op might be more convenient,
>>> it could unconditionally permit operations that formerly required a
>>> permission check: clearly a bad idea. Always throwing a
On Thu, 17 Oct 2024 05:54:24 GMT, Alan Bateman wrote:
>> Ok, I'll also add an API note to `getClassContext()` to use `StackWalker`
>> instead.
>
> Okay, it already has `@see StackWalker`. My guess is that anything extending
> SM to call getClassContext is very old code. If that old code is comp
On Tue, 15 Oct 2024 14:50:54 GMT, Daniel Fuchs wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into J
On Thu, 17 Oct 2024 17:59:20 GMT, Sean Mullan wrote:
>> All JGSS permission classes follow the same style:
>>
>> In `javax.security.auth.kerberos.DelegationPermission`:
>>
>> * This class is used to restrict the usage of the Kerberos
>> * delegation
On Wed, 16 Oct 2024 20:42:11 GMT, Sean Mullan wrote:
>> The description for the SecurityException thrown by these methods were
>> adjusted to "if access to the screen is denied by desktop environment". If
>> you bring back the paragraphs that were removed then you
On Sat, 19 Oct 2024 07:54:07 GMT, Alan Bateman wrote:
> There are a couple of micro benchmarks in test/micro that fork with
> `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be
> examined.
Fixed, will be in next drop. There are a couple of other micro tests that test
th
On Wed, 16 Oct 2024 18:47:44 GMT, Matthew Donovan wrote:
> In this PR, I removed hard-coded security providers and replaced them with a
> system property, test.provider.name. If the property is not specified, the
> provider originally used in the test is used:
>
> Cipher c = Cipher.getInstance
On Wed, 16 Oct 2024 15:53:33 GMT, Alan Bateman wrote:
>> **SLF4J** currently depends on this method when logger name mismatch
>> detection is enabled.
>>
>>
>>
>> See also:
>> - https://github.com/qos-ch/slf4j/pul
On Wed, 16 Oct 2024 06:58:40 GMT, Alan Bateman wrote:
>> Ok, I will revert it.
>
> The description for the SecurityException thrown by these methods were
> adjusted to "if access to the screen is denied by desktop environment". If
> you bring back the paragraphs that were removed then you might
On Wed, 16 Oct 2024 13:28:47 GMT, Weijun Wang wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 22 Oct 2024 08:09:01 GMT, Prasanta Sadhukhan
wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486&#
On Tue, 29 Oct 2024 06:32:59 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/util/concurrent/Executors.java line 529:
>>
>>> 527: * execute the given {@code callable} under the current access
>>> 528: * control context, with the current context class loader as the
>>> 529:
On Mon, 28 Oct 2024 21:02:44 GMT, Sean Mullan wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 175 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' i
ager enabled. After we integrate this JEP,
> those calls will be removed in each area (client-libs, core-libs, security,
> etc).
>
> I don't expect each reviewer to review all the code changes in this JEP.
> Rather, I advise that you only focus on the changes for the area
>
On Fri, 25 Oct 2024 19:55:33 GMT, Roger Riggs wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 150 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JD
On Sun, 27 Oct 2024 00:15:24 GMT, Brent Christian wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' int
On Fri, 25 Oct 2024 20:07:57 GMT, Roger Riggs wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 186 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into J
On Thu, 24 Oct 2024 20:27:33 GMT, Alexey Ivanov wrote:
>> @seanjmullan Can you please advice on some of the following src file javadoc
>> related review comments. Do they need to be handled in this PR? Some of them
>> seem out-of-scope for jep486 PR.
>
> @honkar-jdk I'm inclined to leave it as
On Wed, 23 Oct 2024 11:58:26 GMT, Alan Bateman wrote:
>> test/jdk/java/lang/invoke/RevealDirectTest.java line 33:
>>
>>> 31: * @test
>>> 32: * @summary verify Lookup.revealDirect on a variety of input handles,
>>> with security manager
>>> 33: * @run
>>> main/othervm/policy=jtreg.security.p
ager enabled. After we integrate this JEP,
> those calls will be removed in each area (client-libs, core-libs, security,
> etc).
>
> I don't expect each reviewer to review all the code changes in this JEP.
> Rather, I advise that you only focus on the changes for the area
>
On Mon, 28 Oct 2024 21:00:35 GMT, Sean Mullan wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 186 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into J
ager enabled. After we integrate this JEP,
> those calls will be removed in each area (client-libs, core-libs, security,
> etc).
>
> I don't expect each reviewer to review all the code changes in this JEP.
> Rather, I advise that you only focus on the changes for the area
>
ager enabled. After we integrate this JEP,
> those calls will be removed in each area (client-libs, core-libs, security,
> etc).
>
> I don't expect each reviewer to review all the code changes in this JEP.
> Rather, I advise that you only focus on the changes for the area
>
On Tue, 5 Nov 2024 18:58:22 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in d
On Sun, 3 Nov 2024 12:33:05 GMT, Alan Bateman wrote:
>> Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file)
>> is no longer relevant and should be removed too. Thanks for spotting that.
>
> Removed in jep486 branch in sandbox so will get picked up when PR is
> refreshed.
On Fri, 25 Oct 2024 21:18:41 GMT, Sean Mullan wrote:
> Comments on `java.security` classes.
>
> Also, I'd like to see some clarifications on what "the installed policy" or
> "the current policy" is. The `ProtectionDomain` mentions this when talking
>
On Tue, 29 Oct 2024 18:35:05 GMT, Brent Christian wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 186 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486&#
On Mon, 28 Oct 2024 20:12:27 GMT, Roger Riggs wrote:
> Reviewed all tests under test/jaxp/javax/xml/jaxp. A few imports moved around
> unnecessarily but otherwise looks fine.
JAXP test comments fixed in
https://github.com/openjdk/jdk/pull/21498/commits/5577e4884710eba498ee5f40fa85d47eaa07364d
On Tue, 29 Oct 2024 14:19:05 GMT, Weijun Wang wrote:
>> test/jdk/javax/xml/crypto/dsig/ErrorHandlerPermissions.java line 1:
>>
>>> 1: /*
>>
>> @wangweij It looks like this test can be deleted as it was specifically
>> trying to check that a `SecurityException` wasn't thrown, or did you think
On Fri, 25 Oct 2024 20:44:25 GMT, Roger Riggs wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 150 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JD
On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in d
On Tue, 29 Oct 2024 17:07:56 GMT, Harshitha Onkar wrote:
>> src/java.desktop/share/classes/java/awt/Font.java line 1613:
>>
>>> 1611: * interpreted as a {@code Font} object according to the
>>> 1612: * specification of {@code Font.decode(String)}
>>> 1613: * If the specified prope
ager enabled. After we integrate this JEP,
> those calls will be removed in each area (client-libs, core-libs, security,
> etc).
>
> I don't expect each reviewer to review all the code changes in this JEP.
> Rather, I advise that you only focus on the changes for the area
>
On Wed, 30 Oct 2024 18:12:30 GMT, Matthew Donovan wrote:
>> In this PR, I removed hard-coded security providers and replaced them with a
>> system property, test.provider.name. If the property is not specified, the
>> provider originally used in the test is used:
>>
>> Cipher c = Cipher.getIns
On Wed, 30 Oct 2024 14:48:46 GMT, Matthew Donovan wrote:
>> In this PR, I removed hard-coded security providers and replaced them with a
>> system property, test.provider.name. If the property is not specified, the
>> provider originally used in the test is used:
>>
>> Cipher c = Cipher.getIns
On Wed, 30 Oct 2024 13:09:26 GMT, Matthew Donovan wrote:
>> In this PR, I removed hard-coded security providers and replaced them with a
>> system property, test.provider.name. If the property is not specified, the
>> provider originally used in the test is used:
>>
>> Cipher c = Cipher.getIns
On Tue, 22 Oct 2024 20:23:52 GMT, Roger Riggs wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into J
On Fri, 25 Oct 2024 12:16:55 GMT, Matthew Donovan wrote:
> I changed the name of the bug and PR. Yes there are cases where a test has
> more than one hardcoded provider.
How would that work then if the property only allows you to specify one
provider?
-
PR Comment: https://git.op
On Thu, 24 Oct 2024 15:01:44 GMT, Alexey Ivanov wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 150 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486&
On Fri, 25 Oct 2024 20:34:31 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/security/Security.java line 489:
>>
>>> 487:
>>> 488: /**
>>> 489: * Adds a provider to the next position available..
>>
>> Two periods at t
ager enabled. After we integrate this JEP,
> those calls will be removed in each area (client-libs, core-libs, security,
> etc).
>
> I don't expect each reviewer to review all the code changes in this JEP.
> Rather, I advise that you only focus on the changes for the area
>
On Fri, 25 Oct 2024 20:59:07 GMT, Roger Riggs wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 150 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JD
On Fri, 25 Oct 2024 23:20:02 GMT, Alexander Zuev wrote:
>> Right the JBS is about SM & SecurityException, but the test was repurposed
>> to check if InvalidMidiDataException is thrown and to test this case for
>> code coverage (when it was initially reviewed).
>> I can update the test summary
On Tue, 22 Oct 2024 20:20:16 GMT, Roger Riggs wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into J
On Mon, 21 Oct 2024 22:57:10 GMT, Mandy Chung wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into J
On Fri, 25 Oct 2024 13:44:56 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/io/SerializablePermission.java line 40:
>>
>>> 38: *
>>> 39: * @apiNote
>>> 40: * This permission cannot be used for controlling access to resources
>>>
On Tue, 22 Oct 2024 21:01:24 GMT, Harshitha Onkar wrote:
>> test/jdk/javax/swing/UIDefaults/6795356/TableTest.java line 45:
>>
>>> (failed to retrieve contents of file, check the PR for context)
>> I guess we can test this without SM since it tests SwingLazyValue?
>
> I believe I had removed thi
On Tue, 22 Oct 2024 20:55:30 GMT, Harshitha Onkar wrote:
>> test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java line 49:
>>
>>> 47: SwingUtilities.invokeAndWait(TestJEditor::testJEditorPane);
>>> 48: }
>>> 49:
>>
>> Is there any need to catch the exception and rethrow Runtime
On Wed, 23 Oct 2024 13:07:49 GMT, Daniel Fuchs wrote:
>> test/jdk/java/net/httpclient/websocket/security/WSURLPermissionTest.java
>> line 342:
>>
>>> 340: throws Exception
>>> 341: {
>>> 342: action.run();
>>
>> testWithNoSecurityManager was previously a sanity check, the t
On Fri, 25 Oct 2024 20:48:14 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/security/AccessControlContext.java line 32:
>>
>>> 30:
>>> 31: /**
>>> 32: * AccessControlContext was used with a SecurityManager for access
>>> contro
On Thu, 24 Oct 2024 15:04:08 GMT, Alexey Ivanov wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 150 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486&
On Fri, 25 Oct 2024 23:45:26 GMT, Weijun Wang wrote:
>> I'm not sure what would be a useful message. All the `SecurityManager` check
>> methods throw a `SecurityException` with no message. We had to specify
>> something here because `AccessControlException` doesn't have a no-args ctor.
>
> I se
On Tue, 15 Oct 2024 22:09:59 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/net/URLClassLoader.java line 667:
>>
>>> 665: * @param codesource the codesource
>>> 666: * @throwsNullPointerException if {@code codesource} is {@code
>>
On Thu, 24 Oct 2024 15:57:25 GMT, Alexey Ivanov wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 150 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486&
On Fri, 25 Oct 2024 23:58:33 GMT, Weijun Wang wrote:
>>> The class spec still mentions "permissions which are retrieved by the
>>> system policy by default". Shall we remove it?
>>
>> Yes I think we can remove that text.
>>
>>> Also, getPermissions always returns an empty Permissions object,
On Fri, 25 Oct 2024 20:31:40 GMT, Harshitha Onkar wrote:
>> test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 1:
>>
>>> 1: /*
>>
>> I think we can delete this test. It verifies that popup menus are displayed
>> in a windows `isAlwaysOnTop() == true` in stand-alone apps whereas for
On Fri, 25 Oct 2024 18:52:24 GMT, Alexey Ivanov wrote:
>> @aivanov-jdk
>> On macOS, popup is shifted up and does not cover the taskbar even without
>> SM.
>>
>>> The updated test bug6694823.java works correctly on Windows and displays
>>> its popup over the Windows taskbar — it is expected.
1 - 100 of 123 matches
Mail list logo
