JDK-4182189 : Images loading differerntly from jar vs on disk
  • Type: Bug
  • Component: tools
  • Sub-Component: jar
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_2.5.1
  • CPU: sparc
  • Submitted: 1998-10-16
  • Updated: 1998-10-19
  • Resolved: 1998-10-19
Related Reports
Duplicate :  
Relates :  
Description
> In the following code I get a different response depending on whether
> the class file and images are left on the disk or placed in a jar file.
> In the latter case the is.available() always returns 1, regardless of
> the number of bytes really available:
> 
> Image loadImageAsResource(String resourceName)
> {
>     Image image = null;
> 
>     try
>     {
> 	InputStream is = 
> 	    this.getClass().getResourceAsStream(resourceName);
> 	byte[] bytes = new byte[is.available()];
> 
> 	// !!!!!!!              ^^^^^^^ returns 1 if in class and img
>         // are in jar. Otherwise, returns a correct number
> 
> 	is.read(bytes);
> 	image = this.getToolkit().createImage(bytes);
> 	is.close();
>     }
>     catch (Exception resourceError)
>     {
> 	// react to it
>     }
> 
>     return (image);
> }
> 
> The loading class is not part of a package, but I found out that it does
> not really matter. The input stream returned is a ZipFile, from
> java.util.zip package.
> 

Comments
EVALUATION See bugs 4109069 and 4028605. It is not always possible for InflaterInputStream to know how many bytes are available to be read until after all the data has been read. It has been documented in the method comment. The compromise we made was to always return 1 before EOF and 0 after EOF. ###@###.### 1998-10-19
19-10-1998