File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Strange problem?? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Strange problem??" Watch "Strange problem??" New topic
Author

Strange problem??

Anil Kumar
Greenhorn

Joined: Jan 17, 2004
Posts: 11
I have tried to get a clarification on this but people around could not hep much.
I packaged a .war file into a .ear file with no significant additions, but what seemed strange to me was the fact that the size of ear file was less than that of war file by about 10%.
can anybody explain this??
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Originally posted by Anil Kumar:
I packaged a .war file into a .ear file with no significant additions, but what seemed strange to me was the fact that the size of ear file was less than that of war file by about 10%.

If the WAR and EAR are compressed with a not-very-aggressive compression algorithm, it is conceivable that compressing the WAR a second time could result in a savings. Typically compressing a well-compressed file will increase its size. This isn't a rule, however.
Anil Kumar
Greenhorn

Joined: Jan 17, 2004
Posts: 11
Thanks David,
I was under the impression that jar, war and ear follow the same compression alogoritm as zip which helps us to view these through winzip. Am I wrong?
Anil Kumar
Greenhorn

Joined: Jan 17, 2004
Posts: 11
I zipped a zip file for a second time and the size got reduced by 0.5 %
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Originally posted by Anil Kumar:
I was under the impression that jar, war and ear follow the same compression alogoritm as zip which helps us to view these through winzip. Am I wrong?

If I recall correctly, the ZIP format allows several "strengths" of compression ranging from "none" (just archive) to "strong" (compress as much as possible). Typically, the stronger the compression algorithm, the longer it takes to compress (possible more RAM too).
Note also that different files will be affected differently. It's possible to design a file that will *explode* in size when *compressed* by one algorithm yet *shrink* with another algorithm. Similarly, when sorting a collection, the algorithm's speed is affected by the preexisting order of the elements.
I just checked WinZIP, and when adding files you can specify the compression level: None, Super Fast, Fast, Normal, Maximum (slowest).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Strange problem??