FULL PRODUCT VERSION :
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode)

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

A DESCRIPTION OF THE PROBLEM :
One of the enhancements in JDK 1.6 is to add the method addSourceNameFilter() to the com.sun.jdi.request.ClassPrepareRequest class.  The documentation says setting such a filter will prevent the request from generating events unless refType.sourceNames(someStratam) matches the pattern that was set.  But this isn't so.  The request also causes events to be generated if the source file name(s) of the reference type are not known.  Since the runtime classes shipped with the JRE are compiled in such a way that their source file names are not known to the debugging interface, this causes a ClassPrepareEvent to be triggered on every Java runtime class when using the JRE.  Note that the runtime classes shipped with the JDK are compiled differently, such that their source file names are known, so when using the JDK, events are not generated on the normal Java runtime classes.

The problem with this behavior is that it makes the enhancement much less useful for the intended purpose, namely to trigger an event only when a particular source file is loaded, for the case where a user wants to set a breakpoint in that source file.  The extra events on the reference types whose source file names are not known slows down the debugging session practically to the level that it was before the enhancement.  To circumvent this behavior, I can add class exclusion filters to the ClassPrepareRequest for the Java runtime classes, but now my users can't set breakpoints in these runtime classes for those cases when the source file names ARE known, such as when using the JDK.

Furthermore, stopping on reference types whose source file names are not known is not helpful for breakpoint management, because if the source file name is not known, then the loaded reference type cannot be matched to any "pending" breakpoint, so such an event would have to be ignored by a debugger anyway.

I request that you treat this behavior as a bug and to make the ClassPrepareRequest behave as described by the addSourceNameFilter() Javadoc, namely to stop only when a source file name of a prepared reference type is actually matched against the pattern.  Reference types whose source file name(s) are not known should NOT cause an event to be generated from that request.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a ClassPrepareRequest and use addSourceNameFilter() to restrict the events to classes compiled from a particular source file.  Run the JVM.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The expectation is that events are generated only when a reference type is prepared and one of the source names matches the pattern set in the ClassPrepareRequest.  This is what the JavaDoc says will happen.
ACTUAL -
The actual behavior is that additional events are generated for all reference types whose source name(s) are not known.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Source code can be supplied if necessary, but since programs that use JDI are not usually small, I'll supply this on request.  I don't think it is needed to evaluate this bug report.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The workaround is to set class exclusion filters for the Java runtime classes and to ignore events for reference types whose source file names are not known.  This restricts the capabilities of a debugger, however, unless further complicated options are made available to the user to suppress the use of the class exclusion filters for those cases when they want to set breakpoints in Java runtime classes.