Hei Mandy,
after further investigation I have found several other use cases of
sun.misc.Unsafe::defineClass for which the proposal for JDK-8200559 would
not currently offer a solution. I will try to describe a generic case of
the problem I found:
Java agents sometimes need to communicate state
tcher).
> The proposed API requires more work than the existing
> Unsafe::defineClass that can define a class in any package but
> still plausible, right?
>
> We should explore other alternatives, if any.
>
> Mandy
> [1] http://mail.openjdk.java.net/pipermail/serviceability-de
Hi,
I was wondering if a solution for this problem is still planned for JDK 11
giving the beginning ramp down.
With removing sun.misc.Unsafe::defineClass, Java agents only have an option
to use jdk.internal.misc.Unsafe::defineClass for the use-cases that I
described.
I think it would be a
reate JBS issues for further investigation.
>
> Mandy
>
> On 7/2/18 1:41 AM, Rafael Winterhalter wrote:
>
>> Hi,
>>
>> I was wondering if a solution for this problem is still planned for JDK
>> 11 giving the beginning ramp down.
>>
>> With r
ect any class in any
> package and you can achieve by calling retransformClasses.
>
> What do you think?
>
> Mandy
>
> On 4/18/18 5:23 AM, Rafael Winterhalter wrote:
>
> Hei Mandy,
> Lookup::defineClass would always be an alternative but it would require me
Hi David,
>From my perspective as a heavy user of this API in Unsafe today:
>From my experience, the recursive dependency is not a common problem as
auxiliary types normally only reference the instrumented type. Beyond, this
problem is an issue for such explicit dynamic class loading, also when
Hei Mandy,
I have looked into several Java agents that I have worked on and for many
of them, this API does unfortunately not supply sufficient access. I would
therefore still prefer a method Instrumentation::defineClass.
The problem is that some agents need to define classes in other packages
be different than tool
> agents.
>
> On 4/17/18 5:06 AM, Rafael Winterhalter wrote:
>
> Hei Mandy,
>
> I have looked into several Java agents that I have worked on and for many
> of them, this API does unfortunately not supply sufficient access. I would
> therefore still
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter
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`
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter
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`
ate...@oracle.com>:
> On 16/04/2021 21:09, Rafael Winterhalter wrote:
> > I have never seen a need for a non-agent to define a class in a
> > non-existing package. Injection is typically required if you want to work
> > with package-private types or methods wh
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter
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`
nal -
> > De: "Rafael Winterhalter"
> > À: "core-libs-dev" ,
> "serviceability-dev"
> > Envoyé: Vendredi 16 Avril 2021 15:52:07
> > Objet: RFR: 8200559: Java agents doing instrumentation need a means to
> define auxilary classes
>
> &g
On Fri, 16 Apr 2021 13:44:16 GMT, Rafael Winterhalter
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 wa
and
managerial toll on agent authors. I would hope that an API equally
convenient to today's unsafe options could be added.
Am Fr., 16. Apr. 2021 um 18:35 Uhr schrieb :
>
>
> --
>
> *De: *"Rafael Winterhalter"
> *À: *"Remi Forax"
> *
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`.
-
Commit messages:
- 8200559:
On Fri, 16 Apr 2021 13:44:16 GMT, Rafael Winterhalter
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 wa
> 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 h
of the Instrumentation API methods will throw exceptions in the
future. There would not be much difference if an introduced defineClass
method would do the same.
Am Fr., 16. Apr. 2021 um 19:31 Uhr schrieb Alan Bateman <
alan.bate...@oracle.com>:
> On 16/04/2021 17:40, Rafael Winterhalter wrote:
&g
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter
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`
rather than later. Our goal, then,
> should be to make people’s life
> easier, but only under these constraints, that, at this point, should be
> taken as an axiom for the purpose
> of discussion.
>
> — Ron
>
> > On 20 Apr 2021, at 21:26, Rafael Winterhalter <
> wint
21 matches
Mail list logo
