When getResourceAsStream().available() is called in the class loaded from the Jar file, the return value is different in GNU Classpath and Sun JDK. GNU Classpath: getResourceAsStream().available() returns 0 or 1. Sun's JDK: getResourceAsStream().available() returns actual resource size. This is undocumented behavior, I think it is not a bug. However, it is thought that it is necessary to match GNU Classpath to the behavior of Sun, because there is an application that depends on this behavior.
Created attachment 10083 [details] Test program javac ResourceTest.java mkdir jar jar cf jar\resourcetest.jar ResourceTest.class cd jar java -cp resourcetest.jar ResourceTest
Interesting. This comes from ZipInputStream.available() which according to JCL 2e v1 is specified as: "returns 0 if this ZipInputStream has been closed; otherwise, it returns 1. Unlike the conventional definition of available(), this method does NOT return the actual number of bytes that could be read without blocking." Is this always, or only for (un)compressed jar entries? What are the number you expect with the example you posted?
(In reply to comment #2) > Interesting. This comes from ZipInputStream.available() which according > to JCL 2e v1 is specified as: "returns 0 if this ZipInputStream has been > closed; otherwise, it returns 1. Unlike the conventional definition of > available(), this method does NOT return the actual number of bytes that > could be read without blocking." It seems that Sun's implementation does not return ZipInputStream. ins.getClass().getName() returns "java.util.zip.ZipFile$2" ins is subclass of ZipInputStream returns false. JDK version is: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64) Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing) > Is this always, or only for (un)compressed jar entries? Because I am trying only with compressed jar file yet, I don't know about that. > What are the number you expect with the example you posted? The expected return value is a number of bytes of oritinal resource size (uncompressed size).
I compared operation with Sun JDK1.5 and GNU Classpath about InputStream which ZipFile.getInputStream (ZipEntry) returns. In the case of the compressed ZIP file Sun JDK1.5: Return the value which subtracted the number of read bytes from original file size. GNU Classpath 0.18: When EOF is reached, return 0. 1 is returned when other. In the case of a non-compressed ZIP file Sun JDK1.5: Return the value which subtracted the number of read bytes from file size. GNU Classpath 0.18: Return the same value as Sun JDK1.5. This is not the bug of GNU Classpath. A problem is in the application depending on InputStream.available(). However, since many of such applications exist, I consider that it is better to return the same value as Sun. The sauce depending on available() is introduced also to the following reports of JavaWorld as a sample. To jar or not to jar? Get the lowdown on using Java Archive (jar) files -- including pros and cons http://www.javaworld.com/javaworld/jw-07-1998/jw-07-jar_p.html
We are returning a different input stream: Our code for InflaterInputStream is correct. jamvm -cp ResourceTest.jar ResourceTest java.util.zip.InflaterInputStream@affd3d88 ins.available()=1 sun -cp ResourceTest.jar ResourceTest sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream@82ba41 ins.available()=1156
Fixed!