Miscellaneous improvements to "jar".

[Martin Buchholz]

On Fri, Jun 26, 2009 at 01:37, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

> Am 26.06.2009 02:57, Martin Buchholz schrieb:
>
>> I did some benchmarking,
>> and found that my changes "only" make jar 10-20% faster.
>> Disappointing - we expect an order of magnitude for every commit!
>>
>
> 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.


>
>
>
>> 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.

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

Also, JITs tend to be very good at inlining.


>
> 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.

Martin


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