On 6/29/16 15:47, serguei.spit...@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.spit...@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
