Jigsaw Enhancement RFR round #1: 8156147 Add ClassLoader parameter to new ClassFileTransformer transform method
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Thu Jun 30 03:50:32 UTC 2016
It occurred the bug id in subject has a typo: 8156147 => 8159147.
I will send the RFR round #2 with the correct bug id.
Thanks,
Serguei
On 6/29/16 17:12, Mandy Chung wrote:
>> On Jun 29, 2016, at 4:39 PM, serguei.spitsyn at oracle.com wrote:
>>
>> On 6/29/16 15:47, serguei.spitsyn at oracle.com wrote:
>>> Hi Mandy,
>>>
>>> Thank you for the review and comments.
>>> Nice catch on the @impleSpec.
>>> I'll make the changes.
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 6/29/16 12:45, Mandy Chung wrote:
>>>>> On Jun 28, 2016, at 4:06 AM, serguei.spitsyn at oracle.com wrote:
>>>>>
>>>>> Please, review the Jigsaw fix for the enhancement:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8159147
>>>>>
>>>>>
>>>>> Jdk webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk1/
>>>>>
>>>> ClassFileTransformer.java
>>>>
>>>> Should the given loader parameter require to be the same as Module::getClassLoader? What happens if classBeingRedefined’s class loader != loader or module’s class loader != loader?
>> I forgot to answer this question, sorry.
>>
>> The ClassFileTransformer.transform() method should not be called by the user.
>> It is called from the JPLIS implementation, so that, the loader must be correct.
>> Not sure, if the references are equal but the referenced by the loader parameter
>> ClassLoader object must be the same as returned by the Module::getClassLoader().
>>
>> Do you think we may have a spec problem here?
> Re-reading it, I think it’s fine. The caller to the transform method has to conform to the spec and supply the right loader.
>
> Mandy
More information about the serviceability-dev
mailing list