[Nestmates] RFR (S): Dynamic nestmate update

[Mandy Chung]

On 10/29/18 4:35 PM, David Holmes wrote:
>
>> - At the time class file nest members attributes are parsed and the 
>> nest host setting within the byte stream matches the nest host used 
>> when jvm_lookup_define_class() is invoked, than in my opinion an 
>> error should not result.
>
> I disagree. You're either using dynamic nest membership or you're 
> using static nest membership - using both, even if the end result 
> would be the same, seems an error in the programming model to me. 
> Afterall if the defined class is already a valid static nest member 
> then you don't need to use the NESTMATE property to inject it. And it 
> is definitely an error to claim a static nest-host when the host does 
> not statically list you as a member!

I also considered whether it should be accepted or an error if the 
NestHost attribute exists and matches the nest host class being injected 
it.   I agree with David to separate the static nest membership model 
from dynamic nest membership.  We can revisit that when there is a good 
use case to accept NestHost attribute matching the nest host in the future.
>
>> - Finally, should the setting of nest_host be known at the point 
>> class file load hook is processed?
>
> I'm not sure what you mean. At what point in the current code would 
> the byte[] passed to defineClass be replaced by one from the CLFH? As 
> long as the byte[] is final before we actually set_nest_host, I don't 
> think it matters.
>

JVM TI currently restricts that the retransformation must not change the 
NestHost or NestMembers attributes.  If the class bytes are transformed, 
it will remain as a dynamic nestmate and no NestHost and NestMembers 
attributes.  It seems that the nest host does not need to be known by CFLH.

Mandy