Bug 24596 - Return value of getResourceAsStream().available() in jar file
Summary: Return value of getResourceAsStream().available() in jar file
Status: RESOLVED FIXED
Alias: None
Product: classpath
Classification: Unclassified
Component: classpath (show other bugs)
Version: 0.18
: P3 normal
Target Milestone: 0.91
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-31 14:56 UTC by freebeans
Modified: 2006-04-27 12:11 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-04-03 19:39:40


Attachments
Test program (184 bytes, application/octet-stream)
2005-10-31 15:18 UTC, freebeans
Details

Note You need to log in before you can comment on or make changes to this bug.
Description freebeans 2005-10-31 14:56:42 UTC
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.
Comment 1 freebeans 2005-10-31 15:18:39 UTC
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
Comment 2 Mark Wielaard 2005-10-31 20:48:07 UTC
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?
Comment 3 freebeans 2005-10-31 23:38:43 UTC
(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).
Comment 4 freebeans 2005-11-03 06:11:03 UTC
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 
Comment 5 Lillian Angel 2006-04-03 19:37:56 UTC
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
Comment 6 Lillian Angel 2006-04-03 20:40:21 UTC
Fixed!