I realized after reading Alan's email more closely that an important
difference between his usage and my test yesterday is that he used
_JAVA_OPTIONS whereas I was trying it with just JAVA_OPTS (the latter is
recognized and used by gradle, but the former applies to all exec'ed
java/javac commands even if gradle doesn't pass them along).
Starting with the following:
export _JAVA_OPTIONS="-Dsun.reflect.debugModuleAccessChecks=true
--add-exports-private=java.base/java.lang=ALL-UNNAMED
--add-exports-private=java.base/java.util=ALL-UNNAMED"
I was then able to see the other IllegalAccessExceptions and get much
farther in my build. I ended up needing all of these:
export _JAVA_OPTIONS="-Dsun.reflect.debugModuleAccessChecks=true
--add-exports-private=java.base/java.lang=ALL-UNNAMED
--add-exports-private=java.base/java.util=ALL-UNNAMED
--add-exports-private=java.base/java.lang.invoke=ALL-UNNAMED
--add-exports-private=java.base/java.io=ALL-UNNAMED
--add-exports-private=java.base/java.util.concurrent=ALL-UNNAMED
--add-exports-private=java.base/java.text=ALL-UNNAMED
That was enough to get past compiling buildSrc and start compiling the
javafx.* modules.
I then ran into an unrelated compilation error that I can reproduce
outside of gradle.
-- Kevin
Jochen Theodorou wrote:
On 20.10.2016 10:19, Alan Bateman wrote:
[...]
The latest
proposal in the JSR is an attempt to address that issue but it does
impact code that uses setAccessible to get at non-public types/members
in java.* classes.
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.
[...]
Is the Gradle forum the best place to follow-up on these issues? (I
can't tell from Stephen's mail if it's Gradle or Groovy here).
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.
As for discussion about Gradle with #AwkwardStrongEncapsulation I have
not seen any public discussion about this at gradle yet.
bye Jochen
