When specifying the archived file prefixed with './', gjar will actually create a directory '.' inside the archive and place the file there. This breaks tools, including gij, as obviously the root should directly contain the classes. Trying to archive the current directory by using "." is also affected. This works correctly with sun jar, fastjar, and zip, as seen below: $ jamvm -Xbootclasspath/p:"$(pwd)/tools/tools.zip" gnu.classpath.tools.jar.Main -cf classpath.jar ./COPYING $ /usr/lib/jvm/java-sun/bin/jar -cf sun.jar ./COPYING $ fastjar -cf sun.jar ./COPYING $ zip zip.jar ./COPYING adding: COPYING (deflated 62%) $ unzip -l classpath.jar Archive: classpath.jar Length Date Time Name -------- ---- ---- ---- 25 06-26-07 19:02 META-INF/MANIFEST.MF 17999 06-26-07 19:02 ./COPYING -------- ------- 18024 2 files $ unzip -l sun.jar Archive: sun.jar Length Date Time Name -------- ---- ---- ---- 0 06-26-07 19:02 META-INF/ 71 06-26-07 19:02 META-INF/MANIFEST.MF 17999 07-02-05 23:32 COPYING -------- ------- 18070 3 files $ unzip -l fastjar.jar Archive: fastjar.jar Length Date Time Name -------- ---- ---- ---- 0 06-26-07 19:03 META-INF/ 44 06-26-07 19:03 META-INF/MANIFEST.MF 17999 07-02-05 23:32 COPYING -------- ------- 18043 3 files $ unzip -l zip.jar Archive: zip.jar Length Date Time Name -------- ---- ---- ---- 17999 07-02-05 23:32 COPYING -------- ------- 17999 1 file
---- Hi guys, today I tripped on some weird incompatibility between ecj (3.3.1 as found in Debian Lenny) and gjar 0.95: gjar creates jars which need zip version 2.0 to extract, while e.g. fastjar creates files which are readable by version 1.0. This is what 'file' says: src1-fastjar.jar: Zip archive data, at least v1.0 to extract src1-gjar.jar: Zip archive data, at least v2.0 to extract The problem comes when you want to compile something with ecj and put such a jar (the gjar-created one) in the classpath or bootclasspath. It simply does not find the files! ecj -cp ../src1-gjar.jar use/Test.java ---------- 1. ERROR in use/Test.java (at line 3) import base.Base; ^^^^ The import base cannot be resolved ---------- 2. ERROR in use/Test.java (at line 9) Base b = new Base("Test"); ^^^^ Base cannot be resolved to a type ---------- 3. ERROR in use/Test.java (at line 9) Base b = new Base("Test"); ^^^^ Base cannot be resolved to a type ---------- 3 problems (3 errors)rob@linkist:~/tmp/jartest/src2$ Looking at the jar's content reveals that a class is there: gjar -tf src1-gjar.jar META-INF/MANIFEST.MF ./base/Base.class Who is the one to blame? Is ecj unable to process version 2.0 zip files or does gjar create unsuitable files? Is this a known issue? If you do not believe what you see have a look at the attached sources. Create the two jars using the two shell scripts in src1 and then try to compile the class in src2 using the shell scripts within it. ---- Andrew Haley found out: Note that gjar adds "./" to the start of the path, and jar does not. That's the bug: gjar needs to strip "./" from the start of the path. ---- I further investigated the problem and am convinced too that the problem is in the gjar code. I ruled out the following other situations: - classpath' zip code is broken and should handle ./ entries transparently. This is not the case JDK does the same. I tested this by using ecj with JDK and a gjar-created jar. You get the same error. - classpath' zip code is broken and should remove ./ entries automatically when creating zip files. This is not the case and I found this out by running gjar on JDK. Those files contains ./ prefixes, too. later I added:
Fixed by the following commit: 2007-12-10 Robert Schuster <robertschuster@fsfe.org> PR classpath/32516: * tools/gnu/classpath/tools/jar/Entry.java: (Entry(File, String)): Added loop to remove all dot-file separator prefixes. (Entry(File)): Call Entry(File, String) constructor variant. http://developer.classpath.org/pipermail/classpath-patches/2007-December/005732.html
Marked as fixed in 0.97.