The problem is related to empty paths on the bootclasspath,
and to the JRE issue of not ignoring empty path elements when
looking for resources.

In the Ant build file, we put the value of an Ant variable on the
*JRE* bootclasspath used to run the tests. This is so that
in principle we can profile (etc) the execution of the classes of
the tools we are testing. The value happens to be empty. Because
it is on the JRE bootclasspath, it is not affected by the
fix to ignore empty path elements on the javac bootclasspath.

apt uses a URLClassLoader to locate annotation processors,
using sun.misc.ServiceLoader. This uses the getResource()
mechanism to locate files describing annotation processors.
URLClassLoader always searches up the delegation chain,
including the JRE classloader. This is not an option.

The test prepares jar files containing annotation processors
from files prepared in the current directory.

The net result of all this is that when the test is run, if there
is an empty element on the bootclasspath, it will be treated
as a reference to the current directory when searching for
service configuration files, and so give a "false positive" for
the files in the current directory used to create the last of the
jar files. This false positive shows up during service discovery,
and so causes the expected annotation processors to execute
in the wrong order. This causes the output from this part of the
test to be different from the expected golden file output, and the
test fails.

[[ The processors are being invoked in the wrong order, because
   Round4Apf is being invoked first. This is because the round4apf.jar
   was created *last*, and there is a META-INF/services file left around
   in the current directory, from when round4apf.jar was created. ]]

The fix is to delete the contents of ./META-INF/services after the
jar files have been created, so that an empty element on the
bootclasspath does not accidentally find them.