Given that we will have a NestMate phase 2, i agree with Dan, we can revisit that point later.
Rémi > De: "Daniel Heidinga" <[email protected]> > À: "Karen Kinnear" <[email protected]> > Cc: "valhalla-spec-experts" <[email protected]> > Envoyé: Mercredi 20 Décembre 2017 16:58:03 > Objet: Re: nestmates JVMTI spec proposal changes > We're on board with this proposal. Any change to the NestMembers, adding or > removing members, should fail redefinition. As should changes to NestHost. > Taking this approach now eases the implementation costs and allows us to > re-examine this in the future. > --Dan >> ----- Original message ----- >> From: Karen Kinnear <[email protected]> >> Sent by: "valhalla-spec-experts" >> <[email protected]> >> To: valhalla-spec-experts <[email protected]> >> Cc: >> Subject: nestmates JVMTI spec proposal changes >> Date: Tue, Dec 19, 2017 5:47 PM >> 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 [ >> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.oracle.com_javase_8_docs_platform_jvmti_jvmti.html-23ClassFileLoadHook&d=DwMFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=o8e88cUxfs0Xn3ibrFYJf9-m6XEnAau1Hr_tRPsFNqE&s=J0Lf6yC70kW4MaNf8VLwXaPcEPV4wj0IAIH3yWGvI7Q&e= >> | ClassFileLoadHook ] events, thus the returned error code reflects the >> result >> of the transformations applied to the bytes passed into [ >> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.oracle.com_javase_8_docs_platform_jvmti_jvmti.html-23RedefineClasses.class-5Fdefinitions&d=DwMFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=o8e88cUxfs0Xn3ibrFYJf9-m6XEnAau1Hr_tRPsFNqE&s=F0smHtdTXv7JiNt8sNItG9TAJfAT4UHZdHEId0HXWpQ&e= >> | 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
