PATCH: Tired of waiting for rt.jar to build?

Xueming Shen Xueming.Shen at Sun.COM
Tue Apr 28 06:25:32 UTC 2009

Martin, thanks for the patch, #6834805 has been filed for this issue. 
Will take a look.

Martin Buchholz wrote:
> 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/
> b/src/share/classes/sun/tools/jar/
> --- a/src/share/classes/sun/tools/jar/
> +++ b/src/share/classes/sun/tools/jar/
> @@ -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 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

More information about the core-libs-dev mailing list