Jar tool does not store if it can't compress, deflated file
has problems

Thanks for looking into this. I've attached the first .PNG file that my program fails to load "knight_black.png" from the jar. Note that some of the image files do load okay. The code fragment in my original mail at the bottom is what I am using to read in the image (for both the case of loading from a jar and loading directly from disk files).
 
I've attached the entire JAR file that exposes the image loading problem as well. This includes the application that attempts to load the images. The manifest file does not specify a main class. The main class is 'Scott.Palmer.Chess.ChessGUI'
 
Also note that if use WinZip to extract the knight_black.png file the file is identical to the original input file. I'm not sure what that tells you about why the PNG loader using standard Java APIs fails to read it directly from the jar file.
 
It appears that files that increase in size usually increase by 5 bytes, although some increase by only 3 bytes.
 
F:\Dev\Personal\Java\Chess\classes>jar cvf JChess.jar *.*
added manifest
adding: Chess.bat(in = 34) (out= 31)(deflated 8%)
adding: pieces/(in = 0) (out= 0)(stored 0%)
adding: pieces/default/(in = 0) (out= 0)(stored 0%)
adding: pieces/default/bishop_black.png(in = 1730) (out= 1735)(deflated 0%)
adding: pieces/default/bishop_white.png(in = 317) (out= 313)(deflated 1%)
adding: pieces/default/black_square.png(in = 2244) (out= 2239)(deflated 0%)
adding: pieces/default/king_black.png(in = 1984) (out= 1989)(deflated 0%)
adding: pieces/default/king_white.png(in = 412) (out= 415)(deflated 0%)
adding: pieces/default/knight_black.png(in = 2066) (out= 2071)(deflated 0%)
adding: pieces/default/knight_white.png(in = 371) (out= 371)(deflated 0%)
adding: pieces/default/pawn_black.png(in = 1105) (out= 1110)(deflated 0%)
adding: pieces/default/pawn_white.png(in = 283) (out= 278)(deflated 1%)
adding: pieces/default/Pieces.png(in = 205) (out= 186)(deflated 9%)
adding: pieces/default/queen_black.png(in = 1901) (out= 1906)(deflated 0%)
adding: pieces/default/queen_white.png(in = 387) (out= 388)(deflated 0%)
adding: pieces/default/rook_black.png(in = 459) (out= 464)(deflated -1%)
adding: pieces/default/rook_white.png(in = 282) (out= 276)(deflated 2%)
adding: pieces/default/white_square.png(in = 1545) (out= 1550)(deflated 0%)
...
 
Scott Palmer
 
----- Original Message -----
From: Konstantin Kladko
To: ###@###.###
Cc: Mark Reinhold ; ###@###.### ; ###@###.###
Sent: Monday, November 19, 2001 4:55 PM
Subject: Re: [Scott Palmer] Re: (Review ID: 135519) JAR tool does not 'store' if it can't compress, deflated file has problems

Hi Scott -

sorry for the confusion, this is definitely a bug.

Could you resend me the attachments from your original submission
(.png file, etc) - I do not have them.

Thanks,
Konstantin

>
>
> ------------------------------------------------------------------------
>
> Subject:
>
> Re: (Review ID: 135519) JAR tool does not 'store' if it can't
> compress, deflated file has problems
> From:
>
> ###@###.###
> Date:
>
> Fri, 16 Nov 2001 18:15:33 -0500
> To:
>
> ###@###.###
>
>
> Your review is strange and very unscientific.
>
>
>
> The fact that "out" was greater than "in" and the deflate option was
> used clearly shows that the "store" option was not used when it should
> have been. The fact that it did not show -1% is due only to the
> difference in size from your example to mine. Maybe the jar tool
> never uses the store option, I don't know, nor do I really care as
> that is only a minor problem compared to the second half of my bug
> report dealing with the fact that the data could not be properly
> retrieved from the jar using standard APIs from the JDK.
>
>
>
> For your convenience I have attached the .PNG file that was causing
> problems for me. This file reads fine with the code I provided if it
> is NOT contained in a JAR file, but causes the problems as I indicated
> below when it is loaded from a JAR file with the same code. Note that
> other PNG files in the same JAR DO load properly in my application.
> Therefore it appears that either the jar tool or the APIs to read from
> the jar are broken in some way.
>
>
>
> Please re-evaluate this bug in its entirety using proper scientific
> practices.
>
>
>
> Scott Palmer
>
>
>
> ----- Original Message -----
>
> From: Girish Manwani <mailto:###@###.###>
>
> To: ###@###.###
> <mailto:###@###.###>
>
> Cc: ###@###.### <mailto:###@###.###>
>
> Sent: Friday, November 16, 2001 5:43 PM
>
> Subject: Re: (Review ID: 135519) JAR tool does not 'store' if it
> can't compress, deflated file has problems
>
>
> Hi Scott Palmer,
>
> Thank you for submitting a bug using our bug submit page. I have
> reviewed your
> report and was unable to reproduce the exact error you have mentioned.
>
> I tested the jar tool which comes with JDK 1.4 beta 3, here is
> what i got: -
>
>
> C:\tmp>copy c:\test.png .
> 1 file(s) copied.
>
> C:\tmp>jar cvf new.jar test.png
> added manifest
> adding: test.png(in = 7360) (out= 7365)(deflated 0%)
>
> C:\tmp>dir
> Volume in drive C has no label.
> Volume Serial Number is 786F-CA65
>
> Directory of C:\tmp
>
> 11/16/2001 02:36p <DIR> .
> 11/16/2001 02:36p <DIR> ..
> 11/16/2001 02:36p 7,821 new.jar
> 11/16/2001 02:32p 7,360 test.png
> 2 File(s) 15,181 bytes
> 2 Dir(s) 16,243,400,704 bytes free
>
> C:\tmp>del test.png
>
> C:\tmp>dir
> Volume in drive C has no label.
> Volume Serial Number is 786F-CA65
>
> Directory of C:\tmp
>
> 11/16/2001 02:37p <DIR> .
> 11/16/2001 02:37p <DIR> ..
> 11/16/2001 02:36p 7,821 new.jar
> 1 File(s) 7,821 bytes
> 2 Dir(s) 16,243,408,896 bytes free
>
> C:\tmp>jar xvf new.jar
> created: META-INF/
> extracted: META-INF/MANIFEST.MF
> extracted: test.png
>
> C:\tmp>dir
> Volume in drive C has no label.
> Volume Serial Number is 786F-CA65
>
> Directory of C:\tmp
>
> 11/16/2001 02:37p <DIR> .
> 11/16/2001 02:37p <DIR> ..
> 11/16/2001 02:37p <DIR> META-INF
> 11/16/2001 02:36p 7,821 new.jar
> 11/16/2001 02:37p 7,360 test.png
> 2 File(s) 15,181 bytes
> 3 Dir(s) 16,243,400,704 bytes free
>
> C:\tmp>
>
> Note that the out>in and jar shows Deflated=0% as opposed to your
> claimed (-1%). I believe this could have been a bug before but
> seems to be resolved now.
>
> Thanks again for taking time to report this issue.
>
> Regards,
> Girish
> ----------------- Original Bug Report-------------------
>
> category : java
> release : merlin-beta3
> subcategory : jar
> type : bug
> synopsis : JAR tool does not 'store' if it can't compress,
> deflated file has problems
> description : java version "1.4.0-beta3"
> Java(TM) 2 Runtime Environment, Standard Edition (build
> 1.4.0-beta3-b84)
> Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)
>
> When making a JAR file with the jar tool some files get bigger
> when they are put in the jar, e.g.:
>
> adding: pieces/default/rook_black.png(in = 459) (out=
> 464)(deflated -1%)
>
> PNG graphics are common resources that are effected.
>
> "STORE" mode should be used in this case. But it gets worse...
>
> The problem is that the .PNG files are stored in the jar such that
> the Class method getResourceAsStream( "filename" ) produce a
> corrupt stream that results in:
>
> ava.lang.reflect.InvocationTargetException:
> java.lang.IllegalArgumentException: Width (0) and height (0) must
> be non-zero at
> java.awt.image.ReplicateScaleFilter.<init>(ReplicateScaleFilter.java:86)
> at
> java.awt.image.AreaAveragingScaleFilter.<init>(AreaAveragingScaleFilter.java:61)
> at java.awt.Image.getScaledInstance(Image.java:126)
> AND
>
> sun.awt.image.PNGImageDecoder$PNGException: crc corruption at
> sun.awt.image.PNGImageDecoder.getChunk(PNGImageDecoder.java:722)
> at sun.awt.image.PNGImageDecoder.getData(PNGImageDecoder.java:730)
> at
> sun.awt.image.PNGImageDecoder.produceImage(PNGImageDecoder.java:252)
> at
> sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:257)
> at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:217) at
> sun.awt.image.ImageFetcher.run(ImageFetcher.java:185)
> with the following code:
> InputStream inStream = dummy.getClass().getResourceAsStream(
> "filename" );
> imageData = new byte[ inStream.available() ];
> inStream.read( imageData );
>
> Image i = java.awt.Toolkit.getDefaultToolkit().createImage(
> imageData );
> tracker.addImage(i, 0);
> tracker.waitForAll();
>
> It seems that the file can be extracted from the JAR with WinZIP.
> WinZIP will also make a JAR file with the contents correctly
> compressed ("stored" if they would otherwise get bigger) and the
> WinZIP created JAR does NOT produce the above exceptions whenthe
> resources are loaded at runtime.
> workaround : Use WinZIP to create JAR files.
> suggested_val :
> cust_name : Scott Palmer
> cust_email : ###@###.###
> <mailto:###@###.###>
> jdcid : SWP
> keyword : webbug
> company : N/A
> hardware : x86
> OSversion : windows_2000
> bugtraqID : 0
> dateCreated : 2001-11-12 21:49:57.6
> dateEvaluated : 2001-11-16 15:37:44.852
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com ).
> Version: 6.0.298 / Virus Database: 161 - Release Date: 2001-11-13
>
> ------------------------------------------------------------------------
>
> <cid:###@###.###>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.298 / Virus Database: 161 - Release Date: 2001-11-13


<imap://###@###.###y:143/fetch%3EUID%3E/INBOX%3E8530?part=1.3&type=image/png&filename=knight_black.png>