You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by bu...@apache.org on 2016/03/05 23:23:45 UTC

[Bug 59130] New: Definer's way to parse URLs from classloader breaks with recent Java 9 builds (b108)

https://bz.apache.org/bugzilla/show_bug.cgi?id=59130

            Bug ID: 59130
           Summary: Definer's way to parse URLs from classloader breaks
                    with recent Java 9 builds (b108)
           Product: Ant
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core
          Assignee: notifications@ant.apache.org
          Reporter: uwe@thetaphi.de

Copy from the mail to the OpenJDK mailing list. Lucene found this bug while
testing Java 9 build 108.

In fact, this is a bug in OpenJDK, but in general the way how the Definer class
(base of taskdef, typedef,...) checks if an URL returned by the classloader is
an XML file (to parse as Antlib) or a properties file is likely to break on
non-standard URLs, like those containing a fragment ("#release" in the Jave 9
build).

Nevertheless we should fix the bug:

We tried to build Lucene on our Jenkins server, but the build itsself failed
with a stupid error message:

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:21: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:56:
not doesn't support the nested "matches" element.

What happened was that Ant was not loading its internal conditions/tasks/type
definitions anymore, so the build system does not know almost any type anymore.
The debug log showed that Ant was no longer able to load the resource
"/org/apache/tools/ant/antlib.xml" from its own JAR file anymore. Instead it
printed some strange debugging output (which looked totally broken).

Some debugging showed that Ant tried to parse its own antlib.xml with the
conditions and other types as a properties file instead of XML. This also
caused the broken logging output (fragments of the XML file printed to log file
without any hints).

The reason for this behaviour is the following:

In Java 7, Java 8,... and Java 9pre-b108,
ClassLoader.getResource()/getResources() returnes URLs like: 

"jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml"

Now in Java 9b108 the following is returned:

"jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml#release"

And here Ant breaks. Ant checks for the file extension of the string (because
it may load definitions from both XML and properties files). So it does
endsWith(".xml") and of course this now returns false. The effect is that Ant
tries to load its own task definitions as a java properties file instead of
XML. Of course this fails, because the data behind this URL is XML. The effect
is that Ant cannot bootstrap as everything to build is missing.

The problematic line in Ant's code is here:
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.ant/ant/1.9.6/org/apache/tools/ant/taskdefs/Definer.java?av=f#259

In fact it converts the URL string and checks with .endsWith('.xml'), which
breaks, if an URL fragment is there. A quick workaround is to replace
toString() by getPath() which only returns URL path without fragment and
without scheme/host (SSP). This is better than the old code, but still has the
problem that getPath() may returns the string URL encoded. Ideally one should
use url.toURI().getPath(), which decodes, but this is likely to break with jar:
URLs. In addition, ".xml" should never be URL-encoded, so URL decoding does not
matter. The patch is a one-liner and makes startup of Ant under Java 9 b108
work again. I will send a patch in a minute.

Unfortunately Apache Ivy has a similar problem while loading ivysettings from
its JAR file, so the Lucene build is still broken. But anyways, this bug should
be fixed to prevent similar problem in the future.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 59130] Definer's way to parse URLs from classloader breaks with recent Java 9 builds (b108)

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59130

--- Comment #1 from Uwe Schindler (ASF) <uw...@thetaphi.de> ---
Created attachment 33629
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33629&action=edit
Patch

Patch fixing the issue

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 59130] Definer's way to parse URLs from classloader breaks with recent Java 9 builds (b108)

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59130

Stefan Bodewig <bo...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |1.9.7
         Resolution|---                         |FIXED

--- Comment #2 from Stefan Bodewig <bo...@apache.org> ---
Patch applied.

Thanks a lot for your analysis and for the patch. And in particular thank you
for running the Lucene tests against the EA builds and catching bugs for all of
us.

-- 
You are receiving this mail because:
You are the assignee for the bug.