Hi all, I’ve been asked (by Alan Bateman) to move the discussion that started @ https://discuss.gradle.org/t/classcastexception-from-org-gradle-process-internal-child-bootstrapsecuritymanager/2443 and then moved to email due to technical reasons to this list.
In summary, the way that Gradle mitigates the command line length limit when forking build processes breaks with 9. Mandy Chung’s original post at the link above describes why this breaks. The suggested alternative to the current “trick” of injecting into the application class loader via the security manager is to use a jar with a classpath attribute, thereby reducing the command line length. Gradle has been down this route before, but it broke some tools. One that we have a record of is GWT-Test (https://issues.gradle.org/browse/GRADLE-2223). It will potentially break anything that inspects `java.class.path` or that does the equivalent by `getURLs()` on the application class loader. We don’t really know what the practical impact of this change would be today, but aren’t willing to risk the breaking change to our existing users on < 9. Therefore, in lieu of options file support in 9, our intention is to use the classpath manifest jar approach only on 9. If our users are using any tools that rely on `java.class.path` they may be blocked from moving to 9. We are intending to make this change “soon”. — Join us for Gradle Summit 2015, June 11 - 12 in Santa Clara, CA: http://www.gradlesummit.com
