On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhal...@openjdk.org> wrote:
>> To allow agents the definition of auxiliary classes, an API is needed to >> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or >> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed >> from `sun.misc.Unsafe`. > > Rafael Winterhalter has refreshed the contents of this pull request, and > previous commits have been removed. The incremental views will show > differences compared to the previous content of the PR. The pull request > contains one new commit since the last revision: > > 8200559: Java agents doing instrumentation need a means to define auxiliary > classes This won't work as agents are loaded by the system class loader, not the boot loader. Peter Levart ***@***.***> schrieb am Mo., 19. Apr. 2021, 11:02: > From: Alan Bateman > > JDK-8200559 is about defining auxiliary classes in the same runtime > package at load-time whereas I think the proposal in this PR is adding an > unrestricted defineClass to the Instrumentation class. I think this will > require a lot of discussion as there are significant issues and concerns > here. An unrestricted defineClass might be okay for tool/java agents when > started from the command line with -javaagent but only if the > Instrumentation object is never ever leaked to library or application code. > It could potentially be part of a large effort to reduce the capabilities > of agents loaded via the attach mechanism. More generally I think we need > clearer separation of the requirements of tool agents from the requirement > of framework/libraries that want to inject proxy and other classes at > runtime. > > I think it would be easy to limit the use of this Instrumentation method > to the agent code as agent classes are loaded by the bootstrap classloader. > Simply make the method implementation caller-sensitive and check the caller > is from bootstrap class loader. This way Instrumentation instance escaped > to application code would not give that code any ability to define > arbitrary classes. > > Good enough? > > Peter > > Separately, the proposal in JEP 410 is to terminally deprecate > ProtectionDomain. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/openjdk/jdk/pull/3546#issuecomment-822302347>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABCIA4EYHK5OHTDAN3FKYULTJPWS5ANCNFSM43BSDEGQ> > . > ------------- PR: https://git.openjdk.java.net/jdk/pull/3546
