On Thu, 21 Mar 2024 05:02:17 GMT, Serguei Spitsyn <[email protected]> wrote:
>> Instrumentation.retransformClasses logic can be described by the following
>> pseudo-code:
>>
>> byte[] newClassBytes = JvmtiClassFileReconstituter.reconstitute(klass);
>> for (Transformer tr = firstTransformer(); tr != null; tr = tr->next()) {
>> byte[] transformerClassBytes = tr.transform(newClassBytes);
>> if (newClassBytes != null) {
>> newClassBytes = transformerClassBytes;
>> }
>> }
>>
>> Then newClassBytes is parsed, verified and is used to redefine the class.
>>
>> We need to verify that JvmtiClassFileReconstituter produces correct class
>> bytes, so test transformer can return null or passed classfileBuffer.
>> Actually the issue can be reproduced without ClassFileTransformer at all
>> (and this is mentioned in the CR) - in the case reconstituted class bytes is
>> considered as a result of the instrumentation.
>>
>> I've updated the test, hope it's clearer now.
>> `targetClassName`/`seenClassBytes`/`newClassBytes` was used by Transformer,
>> I moved them to the class.
>> Please let me know if you think some additional comments would be useful.
>
> Thank you for the update, it is a nice change.
> I'd also suggest to add a comment before line 115, something like this:
>
> // Below the null is passed as the classBytes argument which means there
> won't be any transformation.
> // However, it is enough for testing purposes as the
> JvmtiClassFileReconstituter still involved
> // into preparation of the initial classfile bytecodes.
Thank you for the update.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1534563753
