On 21/10/16 10:08, Jochen Theodorou wrote: > I wrote "same class" and thought same class and subclasses... my bad. > Anyway, I am aware of how it works, the problem is that shi... caller > sensitivity. If you work with classic reflection and have a central > space for these kind of actions (for example because that had not really > been caller sensitive before) you get into trouble now.
. . . I had much the same issue to deal with in Byteman. It finesses the caller-sensitivity problem by creating its own special module layer and module at runtime and modifying the package the member belongs so it exports access to the Byteman module. I then inject code into the Byteman module to enable the required access. See the code for release 4.0.0-BETA0 in byteman-layer.jar and byteman-jigsaw.jar for details (you can import the code in byteman-layer to do the module create if you want). My current solution requires an Instrumentation instance to allow the module export redefine to work and then relies on reflection to do the access. So, if gradle were to follow this it would have to employ an agent to acquire an Instrumentation instance. That said, I am currently looking into the use of Lookups following John Rose's suggestion: https://bugs.openjdk.java.net/browse/JDK-8162494 That looks very promising to me and is probably a much better way forward than relying on reflection and modifying the module exports hierarchy. Clearly if you have an agent you can use it to create whatever lookups you need. However, depending on what John et al comes up with by way of a privilege model for acquiring lookups it may avoid the need to have an agent. regards, Andrew Dinn -----------
