Miscellaneous improvements to "jar".

[Ulf Zibis]

Martin, thanks for taking the time.

Am 26.06.2009 15:53, Martin Buchholz schrieb:
>
>
> On Fri, Jun 26, 2009 at 01:37, Ulf Zibis <Ulf.Zibis at gmx.de 
> <mailto:Ulf.Zibis at gmx.de>> wrote:
>
>     1. Hopefully some volunteer would be found to fix
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818737
>     before JDK7 API-freeze.
>     Especially, if jar is not compressed, as in case of normal JDK
>     installation, reading entries from jar should be much faster
>     through java.nio.channels, than via BuffererdInputStream.
>
>
> The way to motivate us around here
> is to provide the prototype implementation that
> demonstrates the speedup.

Sorry, I'm not the specialist on how to provide NIO buffers from native 
memory, and first, I will finish my work on charsets.

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.


>  
>
>
>
>
>         While benchmarking, I discovered to my horror that the simple
>
>         jar cf /tmp/t1 ...
>         jar i /tmp/t1
>
>         fails, because it tries to create the replacement jar in "."
>         and then
>         rename() it into place.  Oops... Better refactor out the code that
>         puts the replacement temp file in the same directory.
>         Better write some tests for that, too.
>
>
>     2. I don't like to refactor out the code in case of only once
>     used, and only to better "comment" what the 2 lines are doing.
>     It blows up the code, and following the code demands annoying
>     scrolling.
>     Better add additional comment to original code.
>
>
> The original code created temp files in *two* places,
> and did it differently.

Oops, at my first search on your code I only found *one* usage of 
createTempFileInSameDirectoryAs(). Did you add the 2nd later?
But there is only one usage of directoryOf(). Shouldn't you inline this?

> I think the name
> createTempFileInSameDirectoryAs
> makes the current code much clearer.

Yes, this is pretty clear, but the cost is 19 lines against 2+2 plus 
demanding the reader for annoying scrolling.
Thinking about directoryOf() I guess, following this strategy you would 
find ten's of locations in Main.java where you could refactor out code 
into small well self-explaining methods, but wouldn't this end up in a 
mess of unreadable blown-up code?

>
> Also, JITs tend to be very good at inlining.

(... after some loops), yes, I know

>  
>
>
>     3. What happens, if original file is exactly named "jartmp"
>     I think you would better add ".tmp" at the end of the filename,
>     and remove it later.
>     Does your new code work with? :
>     jar cf /jartmp/t1 ...
>     jar i /jartmp/t1
>
>
> File.createTempFile doesn't literally create a file named jartmp.
> That's only the prefix.  And it promises to return
> a freshly created empty file.

Now I understand deeper. I just wondered why in fact just renaming "tmp" 
to "jartmp" would resolve your bug. I didn't recognize the 2nd location, 
where wrong "." was used for dir name.

-Ulf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090626/83baa1b9/attachment.html>