Gradle not working on Jigsaw

[Alan Bateman]

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