Re: Re: Re: Class load order

Le 12/01/2010 19:31, Peter Veentjer a écrit :
> Hi Remi, thanks for your help.
>
> How should this functionality be used? I should add logic to the 
> instrumentation process that checks if dependant classes already are 
> loaded? If they are,  i can make use of the extra methods. But if not, 
> i cant add the non existing methods but schedule the class itself and 
> the dependencies that havent been loaded with the redefine 
> functionality? This is the recommended approach?

Oups, I've forget an important limitation of the redefinition, you can 
only change bytecode
of existing methods and not introduce new method.

There is a patch that lift this restriction in mlvm repository but
it will not be integrated before at least first betas of jdk8.

There is another way to solve your problem,
you can insert accessors for fields and unvisible methods to any classes
and generate method code in an helper class if needed (a class you forge
when needed and that can access to any fields using accessors).

Rémi


>
>
>
>
>
> On 12 jan 2010, at 18:40, Rémi Forax <[email protected]> wrote:
>
>> Le 12/01/2010 18:32, Peter Veentjer a écrit :
>>>
>>> Hi guys,
>>>
>>> I'm struggling with an issue that is caused by the order of loading 
>>> classes.
>>>
>>> I add additional methods to classes and this works great. If 
>>> enhanced class A is loaded before enhanced class B, B is allowed to 
>>> call these extra methods of A. But if class B is loaded before class 
>>> A is loaded,  i get à verify error that i'm calling a non existing 
>>> method on A.
>>>
>>> If i manually force loading A before B everything is allright.
>>>
>>> I would like to learn an approach to deal with this problem so that 
>>> the instrumentation process gets more predictable.
>>>
>>> More info about the transformation. I'm building an stm and i add 
>>> transactions to classes. This is done by creating an extra method 
>>> with an extra argument of type transaction. All the original Logic 
>>> is moved to this method. The code in the original method is replaced 
>>> by transaction management code that forwards the call inclusive the 
>>> transaction to the added method.
>>>
>>> The optimization i want to add is that if transactional methods are 
>>> called from the original code, that the method calls are replaced by 
>>> the version that acceps à transaction. There is no need to go 
>>> through the transaction management and access à threadlocal to get 
>>> the transaction.
>>>
>>
>> You can also retransform (or redefine) a class :
>> http://download.java.net/jdk7/docs/api/java/lang/instrument/Instrumentation.html#retransformClasses%28java.lang.Class...%29 
>>
>>
>> Rémi
>>
>> -- 
>> You receive this message as a subscriber of the [email protected] mailing 
>> list.
>> To unsubscribe: mailto:[email protected]
>> For general help: mailto:[email protected]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws