FULL PRODUCT VERSION :
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)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
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" />
		</fileset>

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:

http://forums.sun.com/thread.jspa?threadID=5386732&tstart=0

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

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- 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

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
with JDK 1.5 it comiles much faster than with JDK 1.6
ACTUAL -
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

REPRODUCIBILITY :
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 ----------

CUSTOMER SUBMITTED WORKAROUND :

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.