Summary: | AntClassLoader.findClassInComponents does not work with JDK9-b116+ | ||
---|---|---|---|
Product: | Ant | Reporter: | Vincent Privat <vincent.privat> |
Component: | Core | Assignee: | Ant Notifications List <notifications> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | ||
Priority: | P1 | ||
Version: | 1.9.7 | ||
Target Milestone: | 1.9.8 | ||
Hardware: | All | ||
OS: | All |
Description
Vincent Privat
2016-05-14 12:15:29 UTC
Looks caused by https://bugs.openjdk.java.net/browse/JDK-8137058 fixed in b115. Solution found: add fork="true" to java task. Thank you for reporting this, I'm afraid there isn't anything Ant could do. And many thanks for sharing your "fix". Someone mailed me with question about the changes in JDK 9 with a stack trace very similar to this bug report. Does AntClassLoader have any configuration that would cause it not to delegate to the system or platform class loader for types starting with "jdk." in the name? The javadoc for its loadClass method hints that there might be configuration somewhere that determines whether it delegates or not. Vincent - would it be possible to paste in all steps to duplicate this? We can't see yet whether this is really a JDK 9 issue or not. Sure, here they are: > echo $JAVA_HOME /opt/jdk-9 > svn co -r 10255 https://josm.openstreetmap.de/svn/trunk josm_bug > cd josm_bug > ant clean dist Thanks for the reproducer. Chris Hegarty duplicated the issue and tracked it down to org.apache.tools.ant.util.JavaEnvUtils.buildJrePackages which has a hardcoded list of package prefixed for platform classes. This needs to be updated to allow jdk.** because the JDK has been using this name space since JDK 7. I have updated Chris' patch to take into account Stefan's remarks, added a test case as described in source code, and created a PR on Github: https://github.com/apache/ant/pull/19 Hope this helps. Cheers, Vincent the pull request has been applied to the 1.9.x and master branches, the bug will be fixed in 1.9.8 and 1.10.0 Thanks! |