JDK-6843751 : javac (1.6 update 13) compiles slow if classpath options are too long
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 6u10,6u20
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_xp,windows_7
  • CPU: x86
  • Submitted: 2009-05-21
  • Updated: 2011-10-01
  • Resolved: 2011-08-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Relates :  
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)

Microsoft Windows XP [Version 5.1.2600]

Compile time is very very slow (in comparison to javac of JDK 1.5 Update 11) if the "-classpath" option contains many jars and the path-strings to these jar-files are quite long (tha jar-files are in deiffenet folders of a LOCAL maven repository).

I noticed the problem first when I tried to migrate our projects (which use maven2 as build system) from java 1.5 to java 1.6. Compile times where 3 to 9 times slower for larger projects.

  To prove that the problem is the javac compiler I did the same thing maven does by calling javac with a classpath of 56 jar-files in an argument file. The result was the same. Comiling the source was fast using JDK 1.5 Update 11 and very slow using JDK 1.6 Update 13.

  To be sure that not the unpacking/loading of the jar-files themselves is the problem I compiled the source one time with an ANT buld using a simple path (I copied them all in one directory):

                <fileset dir="./lib">
			<include name="**/*.jar" />

and then having a fileset with long pathnames for each individual file pointing to thei original place in my local maven-repository.

Only the build with the long pathnames is slow.

I can reproduce this on several projects and also on the computers of my co-workers.

For more Details on what I've testet, see:


meanwhile I found the cause of the problem and a workaround.

The difference of the compilation with 1.5 and 1.6 is that javac of 1.6 extends the "search path for class files" based on the Class-Path entries of all the JARs. jacac of 1.5 didn't do that and actually, in my opinion it makes no sense, since the compile- and runtime- classpaths are different.

For details please see Reply#26 and Reply#28 of http://forums.sun.com/thread.jspa?threadID=5386732&tstart=0
A solution could be that javac notices that the classpath option has a different path to othe same jar as the class-path within the manifest
to provide javac with a flag that it should only use the classpath option and ignore the manifest class-path.

As a workaround we just removed the class-paths from our manifests.

- Place many jars (we have about 56) in different folders (e.g the structure of a maven2 repository).

- Compile Source code (I can already see the it��s getting slow by compiling just one source file) by calling
     javac @options.txt @classes.txt
where options.txt contains the "-classpath" pointing to all the jars in different folders by specifying thei Full path and classes.txt the sourcecode of just one javaclass.

- Compare the times if you do the same thing using JDK 1.5 and JDK 6 Update 13

with JDK 1.5 it comiles much faster than with JDK 1.6
compiling the whole project containing 447 sourcefiles, comile times are:

5 seconds using JDK 1.5
47 seconds using JDK 1.6

with just one source-file:
 <1 second with JDK 1.5
  9 seconds with JDSK 1.6

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Should work with any Java class, since loading the classpath seems to be the problem
---------- END SOURCE ----------


none ;-(

Release Regression From : 1.5.0
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

EVALUATION I'm not sure exactly the workaround you are suggesting from 6999460? but SAS tried removing the MANIFESTS and they reported a 20% improvement in compile times. When they turned off Windows File Indexing on the hard drive it did completely resolve the issue. Comments added to 6999460, hopefully this can be fixed soon and relased to SAS in a J4B build?

EVALUATION Question: Do all the entries on all the jar class paths exist? See 6999460 for a solution to a potentially similar problem.