Another IRuntime implementation to address Glassfish issues.
diff --git a/org.jacoco.doc/docroot/doc/implementation.html b/org.jacoco.doc/docroot/doc/implementation.html
index 8474505..e9b07f6 100644
--- a/org.jacoco.doc/docroot/doc/implementation.html
+++ b/org.jacoco.doc/docroot/doc/implementation.html
@@ -220,25 +220,40 @@
</p>
<p>
+
+
Making a runtime library available to all instrumented classes can be a
painful or impossible task in frameworks that use their own class loading
- mechanisms. Therefore JaCoCo decouples the instrumented classes and the
- coverage runtime through official JRE API types. Currently two approaches have
- been implemented:
+ mechanisms. Since Java 1.6 <code>java.lang.instrument.Instrumentation</code>
+ has an API to extends the bootsstrap loader. As our minimum target is Java 1.5
+ JaCoCo decouples the instrumented classes and the coverage runtime through
+ official JRE API types only. Different approaches have been implemented and
+ tested so far:
</p>
<ul>
- <li>By default we use a shared <code>java.util.logging.Logger</code> instance
- to report coverage data to. The coverage runtime registers a custom
- <code>Handler</code> to receive the data. The problem with this approach is
- that the logging framework removes all handlers during shutdown. This may
- break classes that get initialized during JVM shutdown.</li>
- <li>Another approach was to store a <code>java.util.Map</code> instance
- under a system property. This solution breaks the contract that system
- properties must only contain <code>java.lang.String</code> values and has
- therefore caused trouble in certain environments.</li>
+ <li><b><code>SystemPropertiesRuntime</code></b>: This approach stores a
+ <code>java.util.Map</code> instance under a system property containing the
+ execution data. This solution breaks the contract that system properties
+ must only contain <code>java.lang.String</code> values and therefore causes
+ trouble in applications that rely on this definition (e.g. Ant).</li>
+ <li><b><code>LoggerRuntime</code></b>: Here we use a shared
+ <code>java.util.logging.Logger</code> instance to report coverage data to.
+ The coverage runtime registers a custom <code>Handler</code> to receive the
+ data. This approach might break environments that install their own log
+ managers (e.g. Glassfish).</li>
+ <li><b><code>ModifiedSystemClassRuntime</code></b>: This approach adds
+ additional APIs to existing JRE classes through instrumentation. Unlike the
+ other methods above this is only possible for environments where a Java
+ agent is active.</li>
</ul>
+<p>
+ The current JaCoCo Java agent implementation uses the
+ <code>ModifiedSystemClassRuntime</code> adding APIs to the class
+ <code>java.lang.Void</code>.
+</p>
+
<h2>Memory Usage</h2>