InaccessibleObjectException running tests with Java 9 #1095
Comments
|
I can work around this in my own builds by adding the following (the conditional is needed because only a few of my tests run with JVM 9): |
In the most recent builds of Java 9, we now need to pass `--add-opens java.base/java.lang=ALL-UNNAMED` to avoid InaccessibleObjectException instances being thrown from within Gradle internal code.
|
@ChrisAlice Thanks for the well-written issue. I am adding this to our Java 9 epic which we'll prioritize sometime in the next few months. |
|
Same issue when running --status command line option. Can't use buildship with eclipse ( using local gradle distribution). Please refer below stack trace and resolve it, because i love gradle... C:\Users\DK_win10-Asus_3ghz>gradle -v Gradle 3.4-rc-1Build time: 2017-01-26 15:48:49 UTC Groovy: 2.4.7 C:\Users\DK_win10-Asus_3ghz>gradle -S --status FAILURE: Build failed with an exception.
|
|
Same here with 3.4. Any news on this issue? |
|
We are now also facing this issue for Mockito. Would like to see a fix, such that we can properly prepare our library for Java 9. |
|
We are facing the same with Hibernate. |
|
My current findings (don't call this hack a solution) with Travis + jdk-9-162 are:
Travis configuration file: https://github.com/junit-team/junit5/blob/travis_jkd9_build/.travis.yml |
|
+1 |
|
Use new |
|
@sormuras Build is good with the specified Thanks! |
|
The cause is ... no surprise ... that Gradle is poking into the internals of the ClassLoader class. Apparently, in order to find out what packages the system classloader has already loaded so it can expose them without exposing its own internals. FilteringClassLoader is actually the sort of thing Jigsaw is meant to fix more cleanly in the long run: we won't need this kind of classloader games if Gradle itself becomes modularised. However, for now, the issue remains. The above workarounds get the show back on the road temporarily but a better fix would be for Gradle to simply either hard-code the list of "system packages" it actually wants (it seems the current list could be quite affected by random things happening in the system anyway?), or use the Java 9 modules API to reflect java.base and expose all of that. Either approach would avoid the need to bypass visibility and access the classloader internals. |
|
To find the list of Package objects defined by the application class loader, you can use ClassLoader::getDefinedPackages. To find the list of Package objects defined by platform class loader and bootstrap class loader, you can do the following: Set pkgs =
Stream.of(ClassLoader.getSystemClassLoader().getDefinedPackages())
.map(Package::getName)
.collect(Collectors.toSet());
Package[] sysPkgs = Stream.of(Package.getPackages())
.filter(p -> !pkgs.contains(p.getName()))
.toArray(Package[]::new);
On the other hand, FilteringClassLoader::SYSTEM_PACKAGES is a static field that only lists the system packages defined in the runtime at the point when FilteringClassLoader class is initialized and a package is defined only when a class of such package name is loaded. So the question is: should this get the list of all packages in the system modules including the ones that are not yet defined in the runtime? |
|
I think a simple fix for now is to replace the call ClassLoader::getPackages with the suggested code above when running on JDK 9 to get the defined packages by the platform class loader. ClassLoader::getDefinedPackages is a new JDK 9 API. |
|
Yes, that looks like a good improvement. It will fix the problem by avoiding accessing the Java internals. The task the code is doing will remain dubious though. I think what it actually wants to do is more like this: On my Java 9 this yields: which looks reasonable. |
|
The FilteringClassLoader delegates to the platform class loader to define any system class. So I think it should use Module::getPackages and no need to filter isExported. Also it should get all modules defined to the bootstrap class loader and platform class loader. |
This commit fixes the build of the gradle plugin with Java 9. See gradle/gradle#1095
This commit fixes the build of the gradle plugin with Java 9. See gradle/gradle#1095
This commit fixes the build of the gradle plugin with Java 9. See gradle/gradle#1095
This commit fixes the build of the gradle plugin with Java 9. See gradle/gradle#1095
This commit fixes the build of the gradle plugin with Java 9. See gradle/gradle#1095
|
Can confirm broken on 4.0 |
|
@meowingtwurtle Please try the latest 4.1 nightly. |
|
Works on 4.1-20170612195456+0000 with no external JDK_JAVA_OPTIONS |
|
Gradle 4.0 works with JDK 9 at JUnit 5 -- when you set the When you set to When the "kill switch" is the default, those problems will resurface with JDK 10. 🎱
Does 4.1 set the "add-opens" flag automatically? |
This commit fixes the build of the gradle plugin with Java 9. See gradle/gradle#1095
This commit fixes the build of the gradle plugin with Java 9. See gradle/gradle#1095
This commit fixes the build of the gradle plugin with Java 9. See gradle/gradle#1095
|
The final JDK 9 build (b181) defaults to having all packages opened. All workarounds to use --add-opens are no longer needed. However, a warning is still printed during the gradle code execution and it should be fixed. |
|
Sadly that's not the case in my experience. Running Gradle 4.2 with Java 9 results in an error Neither settings Steps to reproduce:
|
|
This is a case where the classes are hidden by default. Also see |
|
Closing as outdated, these illegal accesses have been removed. |
Add build cache configuration to the build
A recent build of Java 9 has broken reflection in Gradle.
Expected Behavior
Tests run
Current Behavior
Context
I'm running my annotation processor against Java 9 to ensure no regressions. Unfortunately it broke a few days ago when Travis started pulling a recent build. Build 9-ea-143 passed; 149 and 150 (the most recent) fail; but I'm unsure about exactly which version of Java 9 introduced the regression.
Steps to Reproduce (for bugs)
https://travis-ci.org/google/FreeBuilder/builds/188953306
Prior to Circle upgrading to Java(TM) SE Runtime Environment build 9-ea+149, this exact configuration passed: https://travis-ci.org/google/FreeBuilder/builds/183979434
Your Environment
https://scans.gradle.com/s/p32r6miu7yevi
The text was updated successfully, but these errors were encountered: