On 20/10/2016 14:48, Jochen Theodorou wrote:
:
I still wish you had at least not included protected members. Sure,
protected is not public and protected is always a pain in the butt, I
still fail to comprehend the logic that a class can extend a class
from another module and then use the protected methods of the super
class, but setAccessible is not allowed to be used to gain access to
it from anywhere but that same class.
This might appear to be an anomaly but remember you don't have the
receiver at this point. You could have setAccessible silently fail so
that the access check happens at newInstance/invoke/get/put but I don't
see anyone being happy with that. That said, if you are using core
reflection to access a protected member in the same package or super
type then you don't need setAccessible in the first place as the access
check should succeed (there have been issues with protected members that
Peter has recently fixed in jdk9/dev, I don't know if you've run into that).
could be Groovy 2.4.7, that kind of error is fixed in 2.4.8... once
it is released, which we are currently working on. Because 2.4.7
assumes either all of the class can be made accessible or none. And
that is not true with #AwkwardStrongEncapsulation anymore. Which also
means meta class creation will take a lot longer, since we now cannot
use the array-taking setAccessible method in all cases anymore. Would
have been nice to have a version of setAccessible that just makes
accessible what is allowed and maybe reports back for those that are
not allowed.
A trySetAccessible is possible although a @CS variant of accessCheck
(like in MH.Lookup) might be more general. I think we need to be
cautious about adding APIs here and so would be interesting to get some
performance data here (I don't think I've seen the bulk setAccessible
used very often, it's almost always the instance method).
As for discussion about Gradle with #AwkwardStrongEncapsulation I have
not seen any public discussion about this at gradle yet.
There is a command-line option to workaround specific usages, I think
part of the challenge is knowing if all usages have been identified and
where to put the VM options (gradle.properties for example) but that's a
discussion for the Gradle forum I guess.
-Alan
