On Mon, 18 Nov 2024 10:50:24 GMT, Kevin Walls wrote:
>> Remove redundant SecurityManager, AccessController references
>> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the
>> Security Manager).
>>
>> test/jdk/java/lang/instrument/ still passing.
>
> Kevin Walls has updat
On Fri, 15 Nov 2024 14:50:21 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 te
On Mon, 18 Nov 2024 06:56:12 GMT, Alan Bateman wrote:
> JDK-8344187 has the changes for the java.instrument module, Kevin has a PR
> coming with the changes.
Thanks, withdrawing this PR. Added label `jep486` to JDK-8344187.
-
PR Comment: https://git.openjdk.org/jdk/pull/22184#issu
Please review this trivial cleanup which removes unused imports of
`java.security.AccessController` and `java.security.PrivilegedAction` from
`java.lang.instrument.ClassFileTransformer`.
History: These imports came with the new transform method introduced by the
module system implementation in
On Sun, 17 Nov 2024 18:04:57 GMT, Eirik Bjørsnøs wrote:
> Please review this trivial cleanup which removes unused imports of
> `java.security.AccessController` and `java.security.PrivilegedAction` from
> `java.lang.instrument.ClassFileTransformer`.
>
> History: These imports ca
Hi,
Last September, Volker shared the observation that we have Hotspot-internal
MBeans in sun.management which are strongly encapsulated and not used
internally by OpenJDK besides their unit tests:
https://www.mail-archive.com/core-libs-dev@openjdk.org/msg19878.html
A summary of the email thread
On Mon, 18 Mar 2024 09:42:13 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which removes per-thread compiler stats from
> `sun.management`
>
> This removes:
>
> * The deprecated interface method
> `HotspotCompilationMBean.getCompilerThreadSt
On Mon, 18 Mar 2024 09:42:13 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which removes per-thread compiler stats from
> `sun.management`
>
> This removes:
>
> * The deprecated interface method
> `HotspotCompilationMBean.getCompilerThreadSt
Please review this cleanup PR which removes per-thread compiler stats from
`sun.management`
This removes:
* The deprecated interface method
`HotspotCompilationMBean.getCompilerThreadStats()` along with the
implementation method in `HotspotCompilation`
* The class returned by these methods, `Co
On Mon, Mar 18, 2024 at 2:31 PM Kevin Walls wrote:
> Right, the existing Deprecated tag had me thinking this was a Java SE
> interface that had begun the deprecation process.
>
> But it's not a published API.
>
Great, it seems we have consensus that we can go ahead and remove these
deprecated me
On Fri, Mar 15, 2024 at 7:54 PM Kevin Walls wrote:
> https://openjdk.org/jeps/277
>
> "An API element should not be removed from the Java SE specification
> unless it has been delivered with an annotation of
> @Deprecated(forRemoval=true) in a previous version of Java SE."
>
>
>
> So deprecation
Hello,
Per-thread compiler performance counters were removed in JDK-8134607 [1]
(JDK 9). The corresponding sun.management API was marked @Deprecated since
it no longer returns any useful counter data.
Has time come to remove this API now?
My understanding is that since sun.management is an inter
>
> Keep in mind two things:
>
> 1. Dynamically loaded agents are more limited in their capabilities than
> agents loaded at startup because redefinition/retransformation is limited
> to changing the body of existing methods. Redefinition can only fix issues
> if you’re lucky.
>
> 2. Java offers no
>
> >Agents are used by profiling tools to instrument Java applications,
> >but agents can also be misused to undermine the integrity of the
> >Java Platform.
>
> I don't think it is fair to assume that profilers are the only "valid"
> use case for agents and imply that all other use ca
14 matches
Mail list logo
