[Bug classpath/32516] gjar may create "." directory into the root of the archive

[thebohemian at gmx dot net]

------- Comment #1 from thebohemian at gmx dot net  2007-12-10 19:40 -------
----

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)address@hidden:~/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:


-- 

thebohemian at gmx dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |thebohemian at gmx dot net
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-12-10 19:40:21
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32516