Miscellaneous improvements to "jar".

[Xueming Shen]

Ulf Zibis wrote:
>
> Motivation:
> Xueming states:
> *"dat" based uses less disk space, but it has larger startup time, 
> reading an additional "big" dat file during class loading/initializing 
> actually takes much longer time than I expected (I hit the extreme 
> when I worked on the EUC_TW, which I make the size only 30% of the 
> existing one, but startup is a disaster regression, ...
> *
> If loading x bytes from dat file via getResourceAsStream() takes much 
> longer time than loading x+30% bytes from class file, processing the 
> UTF-8 conversion, instantiating and initializing additional Class 
> objects, I imperatively presume, that there must be a big chance for 
> significantly improving read speed from uncompressed jar file (here 
> charsets.jar), by using direct channels or how ever. I presume, 
> enhancing reading from jar files would be a big fish in performance 
> gain for the whole JDK, as it is very common task in JVM's daily work.
>
>
Ulf, the "jar reading" part of the "class loading/initializing" of 
charsets.jar (and most of the "core lib" jars) is not via 
java.util.jar/zip interface,
there is a native level interface for the vm to access those jar files, 
so adding a nio buffer interface is not going to help startup of jdk/jre 
itself.
Martin's estimate of 10%-20% gain indeed is very close, I got less than 
5%-8% (for jaring) gain from my prototype implementation. As I
said it's still something worthing doing, especially it makes the life 
easier when work together with other nio/channel APIs.


Sherman