In this section, you learn to change in the Jar and Zip.
Changes in Jar and Zip
In Java SE 6 there are two changes in jar command behavior:
-
Before Java SE 6, the timestamps (date and time) of extracted files by jar command are those listed the current time means extraction time instead of archive file time. But other de/compression tools use the archive time. So in Java SE 6, they do a change in jar command behavior that is the date and time of extracted files by jar command were the archive time. But if the old behavior is needed, use sun.tools.jar.useExtractionTime=true
- At the time of creating a jar, we have the ability in executable jar file to specify the entry point for stand-alone application bundle. The 'e' option declare the entry point through creating or overriding the Main-Class attribute value in the jar file's manifest.
There are some changes in ZIP File also:
- Number of open ZIP files - Prior to Java SE
6, we faced the limitation on the number of concurrently open ZIP files in
Microsoft Windows. And the maximum used to be 2306 but now this limitation
has removed and the maximum used is depend on the whatever the platform will
support.
- Number of entries in a ZIP file - The ZIP
file format was using 2-byte field to record the number of entries in the
file, imposing a 64K limit. But in Java SE 6, ignores that field, just
counts the entries. Before Java 6 you could count the entries with ZipInputStream
or ZipFile, but if
there were more than 64 entries in the file you get the different result.
- ZIP File Names - Java SE 6 support the file
names longer than 256 characters.
-
API Changes - There are two new compressed streams have been added :
- java.util.zip.DeflaterInputStream -
This stream is used to read the compressed data. For example, This stream
can be useful if any client want to send the data in compressed form
over a network and it can compressed into packets by DeflaterInputStream.
-
java.util.zip.InflaterOutputStream - This stream is used to write the decompressed data. For example, At the receiving end decompresses the compressed packet by writing to an InflaterOutputStream.