Miscellaneous improvements to "jar".
martinrb at google.com
Fri Jun 26 06:53:09 PDT 2009
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
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the core-libs-dev