Greetings, jar team!
Recent changes by Xueming have made building rt.jar an order of
magnitude faster.
But it's still too slow for our taste.
Here's another order of magnitude...
In our tests, this reduces rt.jar build time to 2 sec (!)
diff --git a/src/share/classes/sun/tools/jar/Main.java
b/src/share/classes/sun/tools/jar/Main.java
--- a/src/share/classes/sun/tools/jar/Main.java
+++ b/src/share/classes/sun/tools/jar/Main.java
@@ -56,7 +56,7 @@
Set<File> entries = new LinkedHashSet<File>();
// Directories specified by "-C" operation.
- List<String> paths = new ArrayList<String>();
+ Set<String> paths = new HashSet<String>();
CRC32 crc32 = new CRC32();
/*
contributed by Jeremy Manson, who writes:
"""Basically, rt.jar seems to be built by taking a huge long list of
directories:
jar -C dir class -C dir class -C dir class <repeat 16000 times>
All of these directories are *exactly the same place*. However, the jar command
gives each a separate entry in the big list of directories.
For each class, it iterates through all 16000 identical entries to find the
right directory. Using HashSet reduces the size of this set to 1."""
Now, this is a behavior-preserving change, but the current code that uses
paths in Main.java is extremely suspect. I believe the better fix would be
to eviscerate the code that handles the "-C" flag and do it right,
but the change above is much lower risk, and users have been living
with the current misbehavior of "jar" for a very long time indeed.
So, reviewers, the choice is yours - optimize the buggy behavior,
or replace it with correct code, that will likely be even faster.
Also, please file a bug.
Someone who cares about the Makefiles can also try to remove the
16000 gratuitous -C flags that makes jar's life "jar hell".
Martin
