Clean backport to JDK 25.
This change recently integrated in JDK 26 and is through tiers 1 - 4 so far.
-
Commit messages:
- Backport 13a3927855da61fe27f3b43e5e4755d0c5ac5a16
Changes: https://git.openjdk.org/jdk/pull/26088/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26
On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo
wrote:
>> Please review this small test fix. We need to make sure the two threads are
>> blocked on the expected locks before invoking findMonitorDeadlockedThreads.
>> In the failing cases, one of the threads is seen as blocked while wait
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 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 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 Wed, 5 Feb 2025 15:51:25 GMT, Daniel Fuchs wrote:
>> java.util.logging.LoggingMXBean and
>> java.util.logging.LogManager::getLoggingMXBean are deprecated since
>> JDK-8139982 in JDK 9.
>>
>> These deprecations should be uprated to state they are for future removal.
>>
>> java.util.logging.
On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls wrote:
> java.util.logging.LoggingMXBean and
> java.util.logging.LogManager::getLoggingMXBean are deprecated since
> JDK-8139982 in JDK 9.
>
> These deprecations should be uprated to state they are for
java.util.logging.LoggingMXBean and
java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982
in JDK 9.
These deprecations should be uprated to state they are for future removal.
java.util.logging.Logging (implements LoggingMXBean) should also be deprecated
for removal.
On Wed, 8 Jan 2025 11:03:06 GMT, Joakim Nordström
wrote:
>> Could I get a review of this fix to refine the warnings printed by `libjsig`
>> when using the deprecated `signal()`/`sigset()` functions?
>>
>> Currently the libjsig library supports chaining `signal()` and `sigset()`.
>> With these
On Wed, 8 Jan 2025 11:03:06 GMT, Joakim Nordström
wrote:
>> Could I get a review of this fix to refine the warnings printed by `libjsig`
>> when using the deprecated `signal()`/`sigset()` functions?
>>
>> Currently the libjsig library supports chaining `signal()` and `sigset()`.
>> With these
On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie wrote:
>> Some files have been modified in 2024, but the copyright year has not been
>> properly updated. This should be fixed.
>>
>> I have located these modified files using:
>>
>> git log --since="Jan 1" --name-only --pretty=format: | sor
On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie wrote:
>> Some files have been modified in 2024, but the copyright year has not been
>> properly updated. This should be fixed.
>>
>> I have located these modified files using:
>>
>> git log --since="Jan 1" --name-only --pretty=format: | sor
On Thu, 5 Dec 2024 10:20:50 GMT, Alan Bateman wrote:
> We hollowed out ReflectUtil as one of the early steps when removing the code
> for running in the SecurityManager execution mode. Most of the usages have
> now been removed so the empty (and unused) methods can be removed. FieldUtils
> and
On Tue, 3 Dec 2024 09:03:20 GMT, Jaikiran Pai wrote:
> Although trivial, there are some changes to files from the serviceability
> area. So it would be good if someone from that area could review this too.
Yes, looks good. I will update https://github.com/openjdk/jdk/pull/22478 to
avoid the c
On Tue, 3 Dec 2024 06:12:13 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which removes usages of
>> SecurityManager related APIs and some leftover related to SecurityManager
>> changes?
>>
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these
>>
On Thu, 28 Nov 2024 15:52:01 GMT, Alan Bateman wrote:
>> test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line
>> 96:
>>
>>> 94: .shouldContain("Read I/O pollers:")
>>> 95: .shouldContain("Write I/O pollers:")
>>> 96: .should
On Thu, 28 Nov 2024 15:54:54 GMT, Alan Bateman wrote:
>> Adds `jcmd Thread.vthread_scheduler` to print the virtual thread
>> scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers
>> that support virtual threads doing blocking network I/O operations.
>>
>> This is a subset of t
On Wed, 27 Nov 2024 15:59:17 GMT, Alan Bateman wrote:
> Adds `jcmd Thread.vthread_scheduler` to print the virtual thread
> scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers
> that support virtual threads doing blocking network I/O operations.
>
> This is a subset of the di
On Fri, 15 Nov 2024 01:12:34 GMT, Stuart Marks wrote:
> First cut at removal of Security Manager stuff from RMI.
>
> This covers just about every SM-related case in RMI, except for a bit of
> package checking in MarshalInputStream. This will be handled separately. It's
> covered by [JDK-834432
On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote:
> Currently, the man pages are stored as troff (a text format) in the open
> repo, and a content-wise identical copy is stored as markdown (another text
> format) in the closed repo.
>
> Since markdown is preferred to troff in terms o
On Tue, 12 Nov 2024 14:44:55 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 detail the
>> main ch
On Tue, 12 Nov 2024 13:01:33 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 detail the
>> main ch
On Fri, 18 Oct 2024 19:03:30 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 detail the
>> main ch
On Fri, 18 Oct 2024 19:03:30 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 detail the
>> main ch
On Thu, 15 Aug 2024 20:28:28 GMT, Dhamoder Nalla wrote:
>> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code
>> across the OpenJDK repository to retrieve the temporary directory path, as
>> GetTempPath2 provides enhanced security. While GetTempPath may still
>> function
On Mon, 16 Sep 2024 09:21:22 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only change which replaces the usage
> of `-noclassgc` with `-Xnoclassgc` option when launching the test?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8340176, the `-noclassgc` is
> an undocum
On Thu, 15 Aug 2024 20:28:28 GMT, Dhamoder Nalla wrote:
>> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code
>> across the OpenJDK repository to retrieve the temporary directory path, as
>> GetTempPath2 provides enhanced security. While GetTempPath may still
>> function
On Mon, 9 Sep 2024 06:28:45 GMT, Alan Bateman wrote:
>> This PR proposes to add a JDK-specific monitoring and management interface
>> for the virtual thread scheduler. The interface is named
>> [VirtualThreadSchedulerMXBean](https://download.java.net/java/early_access/loom/docs/api/jdk.manageme
On Thu, 5 Sep 2024 17:54:46 GMT, Alan Bateman wrote:
>> This PR proposes to add a JDK-specific monitoring and management interface
>> for the virtual thread scheduler. The interface is named
>> [VirtualThreadSchedulerMXBean](https://download.java.net/java/early_access/loom/docs/api/jdk.manageme
On Thu, 15 Aug 2024 20:28:28 GMT, Dhamoder Nalla wrote:
>> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code
>> across the OpenJDK repository to retrieve the temporary directory path, as
>> GetTempPath2 provides enhanced security. While GetTempPath may still
>> function
On Fri, 19 Jul 2024 16:59:54 GMT, Alan Bateman wrote:
>> Bringover some of the changes accumulated in the loom repo to the main line,
>> most of these changes are test updates and have been baking in the loom repo
>> for several months. The motive is partly to reduce the large set of changes
>
There are two similarly names tests.
Recently:
JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed
with CPU time out of expected range
...made a simple change to try and avoid noisy test failures. The same fix
should be applied here to ThreadCpuTime.java.
Also removing a
On Fri, 21 Jun 2024 14:05:51 GMT, Kevin Walls wrote:
> Man page update for JDK-8327793 which marked jstatd as deprecated for removal
> in JDK 24.
Thanks Alan and David, moving to a single line:
JSTATD(1) JDK
Co
> Man page update for JDK-8327793 which marked jstatd as deprecated for removal
> in JDK 24.
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:
text update
-
Changes:
- all: https://git.openjdk.org/jdk/pull/19829
On Fri, 21 Jun 2024 14:05:51 GMT, Kevin Walls wrote:
> Man page update for JDK-8327793 which marked jstatd as deprecated for removal
> in JDK 24.
The updated man page looks like:
JSTATD(1) JDK
Co
Man page update for JDK-8327793 which marked jstatd as deprecated for removal
in JDK 24.
-
Commit messages:
- 8334287: Man page update for jstatd deprecation
Changes: https://git.openjdk.org/jdk/pull/19829/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19829&range=00
Is
On Tue, 11 Jun 2024 13:09:06 GMT, Kevin Walls wrote:
> jstatd is an RMI server application which monitors HotSpot VMs, and provides
> an interface to the monitoring tool jstat, for use across a remote RMI
> connection.
>
> RMI is not how modern applications communicate. It is a
On Fri, 21 Jun 2024 13:13:38 GMT, Kevin Walls wrote:
>> jstatd is an RMI server application which monitors HotSpot VMs, and provides
>> an interface to the monitoring tool jstat, for use across a remote RMI
>> connection.
>>
>> RMI is not how modern applicat
and configuration difficulties with firewalls.
>
> The jstatd tool should be removed. Deprecating and removing jstatd will not
> affect usage of jstat for monitoring local VMs using the Attach API.
Kevin Walls has updated the pull request incrementally with one additional
commit since
On Fri, 21 Jun 2024 12:28:20 GMT, Alan Bateman wrote:
>> For the Security Manager, the warning was worded a little differently:
>>
>> "WARNING: The Security Manager is deprecated and will be removed in a future
>> release"
>>
>> I think that wording is more clear. The current wording could be
and configuration difficulties with firewalls.
>
> The jstatd tool should be removed. Deprecating and removing jstatd will not
> affect usage of jstat for monitoring local VMs using the Attach API.
Kevin Walls has updated the pull request incrementally with one additional
com
and configuration difficulties with firewalls.
>
> The jstatd tool should be removed. Deprecating and removing jstatd will not
> affect usage of jstat for monitoring local VMs using the Attach API.
Kevin Walls has updated the pull request with a new target base due to a merge
or a reb
On Thu, 20 Jun 2024 15:24:35 GMT, Kevin Walls wrote:
> 844: JMX attaching of Subject does not work when security manager not
> allowed
This pull request has now been integrated.
Changeset: 23f2c97f
Author: Kevin Walls
URL:
https://git.openjdk.org/jdk/
On Thu, 20 Jun 2024 15:24:35 GMT, Kevin Walls wrote:
> 844: JMX attaching of Subject does not work when security manager not
> allowed
Thanks Daniel. Testing automated and manual looks good in 24 and in this 23
backport, so I'll get this integrated.
-
PR Com
844: JMX attaching of Subject does not work when security manager not
allowed
-
Commit messages:
- Backport bcf4bb4882e06d8c52f6eb4e9c4e027ba0622c5f
Changes: https://git.openjdk.org/jdk/pull/19810/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19810&range=00
Issue:
On Mon, 10 Jun 2024 11:28: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.s
On Tue, 18 Jun 2024 12:17:46 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 neede
On Wed, 19 Jun 2024 11:21:45 GMT, Daniel Fuchs wrote:
> The code changes look good to me (if a bit verbose) and the test changes look
> reasonable. It could be beneficial to add some more tests in the future
> involving monitoring and getting the subject from within a monitored MBean.
Yes, agr
On Tue, 18 Jun 2024 11:33:51 GMT, Daniel Fuchs wrote:
>> Agree with Kevin. To minimize risk, especially since this is to fix a
>> significant regression and we are in RDP1, we are really trying to preserve
>> the existing code as much as possible, even though it could be improved.
>
> It is als
> 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=allow to use JMX authentication.
Kevin Wa
On Mon, 17 Jun 2024 20:51:34 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 neede
On Mon, 17 Jun 2024 20:51:34 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 neede
> 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=allow to use JMX authentication.
Kevin Wa
> 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=allow to use JMX authentication.
Kevin Wa
On Mon, 17 Jun 2024 13:58:11 GMT, Daniel Fuchs wrote:
>> Kevin Walls has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - style update
>> - whitespace
>
> src/java.management.rmi/share
On Mon, 17 Jun 2024 12:33:08 GMT, Weijun Wang wrote:
>> Kevin Walls has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - leave noPermissionsACC in place for now
>> - leave noPermissionsACC in place for n
> 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=allow to use JMX authentication.
Kevin Wa
On Mon, 17 Jun 2024 12:33:47 GMT, Weijun Wang wrote:
>> Kevin Walls has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - leave noPermissionsACC in place for now
>> - leave noPermissionsACC in place for now
On Fri, 14 Jun 2024 14:48:14 GMT, Weijun Wang wrote:
> > Does noPermissionsACC add anything?
>
> I don't know. My principal for this code change is that nothing is changed
> for the SM-is-allowed case.
I've put back the noPermissionsACC for this change, it does not have to be
removed in this
> 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=allow to use JMX authentication.
Kevin Wa
On Sun, 16 Jun 2024 01:54:34 GMT, Weijun Wang wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Unnecessary catches to remove
>
> src/java.management/share/classes/javax/management/mon
> 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=allow to use JMX authentication.
Kevin Wa
On Fri, 14 Jun 2024 14:51:53 GMT, Weijun Wang wrote:
>> It needs to recognise and throw RuntimeException so that a SecurityException
>> isn't wrapped in a PrivilegedActionException (which gets caught by those
>> blocks of code which call extractException(pe) and look at what Exception
>> it c
> 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=allow to use JMX authentication.
Kevin Wa
On Fri, 14 Jun 2024 12:03:07 GMT, Weijun Wang wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Separate SM allowed and not allowed cases
>
> src/java.management.rmi/share/class
On Wed, 12 Jun 2024 20:52:51 GMT, Sean Mullan wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>>Undo test policy updates
>
> src/java.management/share/classes/javax/management/mon
> 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=allow to use JMX authentication.
Kevin Wa
On Fri, 14 Jun 2024 12:44:17 GMT, Kevin Walls wrote:
>> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java
>> line 353:
>>
>>> 351: } else {
>>> 352: return Subject.getSubject(Acc
> 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=allow to use JMX authentication.
Kevin Wa
On Fri, 14 Jun 2024 12:04:06 GMT, Weijun Wang wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Separate SM allowed and not allowed cases
>
> src/java.management/share/class
On Fri, 14 Jun 2024 12:09:46 GMT, Weijun Wang wrote:
> I don't quite understand why there is no more `noPermissionsACC` in
> `Monotor.java`. This looks like the only behavior change when SM is allowed.
> The other source change looks fine to me.
Does noPermissionsACC add anything? Maybe I'm r
On Wed, 12 Jun 2024 21:03:17 GMT, Sean Mullan wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>>Undo test policy updates
>
> src/java.management.rmi/share/classes/javax/management/rem
On Tue, 11 Jun 2024 19:01:45 GMT, Weijun Wang wrote:
>> Thanks I'll go through the above comments and update - some of the changes I
>> see are unnecessary and from when I was trying migrating to callAs, and
>> doPrivileged, and yes they can be simpler.
>>
>> On the allowSecurityMananger check
> 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=allow to use JMX authentication.
Kevin Wa
> 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=allow to use JMX authentication.
Kevin Wa
> 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=allow to use JMX authentication.
Kevin Wa
On Wed, 12 Jun 2024 16:41:36 GMT, Daniel Fuchs wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>>Undo test policy updates
>
> src/java.management.rmi/share/classes/javax/management/rem
On Wed, 12 Jun 2024 20:42:27 GMT, Sean Mullan wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>>Undo test policy updates
>
> src/java.management/share/class
> 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=allow to use JMX authentication.
Kevin Wa
On Wed, 12 Jun 2024 14:55:31 GMT, Daniel Fuchs wrote:
>> Hmm I may have fixed that since changing the policy files, as I'm not seeing
>> the problem without that AuthPermission any more. Am just retesting
>> everything before updating this...
>
> (Same with other policy files in which the perm
> 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=allow to use JMX authentication.
Kevin Wa
> 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=allow to use JMX authentication.
Kevin Wa
On Wed, 12 Jun 2024 14:31:26 GMT, Alan Bateman wrote:
>> test/jdk/javax/management/remote/mandatory/notif/policy.negative line 7:
>>
>>> 5: permission javax.management.MBeanPermission
>>> "[domain:type=NB,name=2]", "addNotificationListener";
>>> 6: permission javax.management.MBeanPermi
On Tue, 11 Jun 2024 20:31:03 GMT, Sean Mullan wrote:
>> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java
>> line 350:
>>
>>> 348: @SuppressWarnings("removal")
>>> 349: private Subject getSubject() {
>>> 350: Subject subject = null;
>>
>> J
On Tue, 11 Jun 2024 16:55:44 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/RMICo
> 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=allow to use JMX authentication.
Kevin Wa
On Tue, 11 Jun 2024 16:53:09 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/RMICo
On Tue, 11 Jun 2024 20:58:54 GMT, Sean Mullan wrote:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>> line 1436:
>>
>>> 1434: } else {
>>> 1435: // ACC is present, we have a Subject and SM is
>>> permitted:
>>> 1436:
On Tue, 11 Jun 2024 16:59:31 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/share/classes/javax/management/monitor/Monitor
and configuration difficulties with firewalls.
>
> The jstatd tool should be removed. Deprecating and removing jstatd will not
> affect usage of jstat for monitoring local VMs using the Attach API.
Kevin Walls has updated the pull request incrementally with one additional
com
On Tue, 11 Jun 2024 17:03:58 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/RMICo
and configuration difficulties with firewalls.
>
> The jstatd tool should be removed. Deprecating and removing jstatd will not
> affect usage of jstat for monitoring local VMs using the Attach API.
Kevin Walls has updated the pull request incrementally with two additional
comm
On Tue, 11 Jun 2024 16:54:36 GMT, Kevin Walls wrote:
>> jstatd is an RMI server application which monitors HotSpot VMs, and provides
>> an interface to the monitoring tool jstat, for use across a remote RMI
>> connection.
>>
>> RMI is not how modern applicat
On Tue, 11 Jun 2024 13:35:19 GMT, Alan Bateman wrote:
> The sun.jvmstat.monitor.remote package is not exported so I don't think
> adding `@Deprecated` makes sense.
Sure, happy to not add annotations in sun.jvmstat.monitor.remote
(RemoteHost.java, RemoteVm.java).
-
PR Comment: htt
and configuration difficulties with firewalls.
>
> The jstatd tool should be removed. Deprecating and removing jstatd will not
> affect usage of jstat for monitoring local VMs using the Attach API.
Kevin Walls has updated the pull request incrementally with one additional
commit sin
> 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=allow to use JMX authentication.
Kevin Wa
On Tue, 11 Jun 2024 14:02:17 GMT, Sean Mullan wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> More consistent style of calls and comments.
>
> test/jdk/javax/man
jstatd is an RMI server application which monitors HotSpot VMs, and provides an
interface to the monitoring tool jstat, for use across a remote RMI connection.
RMI is not how modern applications communicate. It is an old transport with
long term security concerns, and configuration difficulties
> 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=allow to use JMX authentication.
Kevin Wa
On Mon, 10 Jun 2024 14:28:25 GMT, Alan Bateman 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.manage
1 - 100 of 129 matches
Mail list logo
