I believe we are all in agreement that: 1. Redefinition should NOT be allowed to change the NestHost attribute and 2. Redefinition should NOT be allowed to remove NestMembers (equivalent to reducing access controls)
The question was - should we allow Redefinition to add NestMembers or not? Hotspot team would like to propose that at least for the initial nestmates release - we do NOT allow Redefinition to add NestMembers. In all cases, NOT allow would mean a failure to redefine a class. Open to suggestions on error that should be returned. This is the least risky approach and allows future reducing restrictions if we find we need to. It is extremely difficult to increase restrictions. Discussion: JVMTI redefinition restrictions today: The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, change modifiers, or change inheritance. These restrictions may be lifted in future versions. See the error return description below for information on error codes returned if an unsupported redefinition is attempted. The class file bytes are not verified or installed until they have passed through the chain of ClassFileLoadHook <https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#ClassFileLoadHook>events, thus the returned error code reflects the result of the transformations applied to the bytes passed into class_definitions <https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#RedefineClasses.class_definitions>. If any error code is returned other than JVMTI_ERROR_NONE, none of the classes to be redefined will have a new definition installed. When this function returns (with the error code of JVMTI_ERROR_NONE) all of the classes to be redefined will have their new definitions installed. Note that redefinition today is not allowed to change modifiers or change inheritance, so no changes that could change access control behavior. The jigsaw AddExports allows dynamic increasing of access to types. To ensure that resolution of a constant pool type entries that fails always fails in the same way, the implementation must cache those failures. If we were to allow dynamic increases in member access, to ensure that resolution of content pool member entries (fields, methods) would fail in the same way, the implementation would need to cache those resolution failures, which is non-trivial, and would need to ensure that the redefinition implementation retained errors for resolution from other types. Note that Redefinition is allowed to change inner class attributes today; however those do not have any affect on the JVM, they just change what reflection returns. Redefinition does not allow adding trampoline methods. thanks, Karen
