Jigsaw Enhancement RFR round #1: 8156147 Add ClassLoader parameter to new ClassFileTransformer transform method

[serguei.spitsyn at oracle.com]

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?

Thanks,
Serguei


>>
>>   209      * @implSpec The default implementation of this method 
>> invokes the
>>   210      * {@link 
>> #transform(ClassLoader,String,Class,ProtectionDomain,byte[]) transform}
>>   211      * method with the {@link Module#getClassLoader() 
>> ClassLoader} for the module.
>>
>> This @implSpec needs update - no longer call Module::getClassLoader.
>>
>>   215      *   may be <code>null</code> if the bootstrap loader
>>
>> Nit: replace <code></code> with {@code null}
>>
>> Other than above, looks fine.
>>
>> Mandy
>