JDK 8 code review request for doclint issues in java.lang.instrument

[Joe Darcy]

Hello,

Yet another found of doclint fixes for review; this batch to 
java.lang.instrument.

Thanks,

-Joe

diff -r 9eaeb1a0aa46 
src/share/classes/java/lang/instrument/Instrumentation.java
--- a/src/share/classes/java/lang/instrument/Instrumentation.java Sun 
Jun 30 17:15:47 2013 -0700
+++ b/src/share/classes/java/lang/instrument/Instrumentation.java Mon 
Jul 01 11:23:19 2013 -0700
@@ -363,6 +363,8 @@
       * Primitive classes (for example, 
<code>java.lang.Integer.TYPE</code>)
       * and array classes are never modifiable.
       *
+     * @param theClass the class to check for being modifiable
+     * @return whether or not the argument class is modifiable
       * @throws java.lang.NullPointerException if the specified class 
is <code>null</code>.
       *
       * @see #retransformClasses
@@ -549,14 +551,14 @@
       * {@link java.lang.instrument.ClassFileTransformer 
ClassFileTransformer},
       * it enables native methods to be
       * instrumented.
-     * <p/>
+     * <p>
       * Since native methods cannot be directly instrumented
       * (they have no bytecodes), they must be wrapped with
       * a non-native method which can be instrumented.
       * For example, if we had:
       * <pre>
       *   native boolean foo(int x);</pre>
-     * <p/>
+     * <p>
       * We could transform the class file (with the
       * ClassFileTransformer during the initial definition
       * of the class) so that this becomes:
@@ -567,14 +569,14 @@
       *   }
       *
       *   native boolean wrapped_foo(int x);</pre>
-     * <p/>
+     * <p>
       * Where <code>foo</code> becomes a wrapper for the actual native
       * method with the appended prefix "wrapped_".  Note that
       * "wrapped_" would be a poor choice of prefix since it
       * might conceivably form the name of an existing method
       * thus something like "$$$MyAgentWrapped$$$_" would be
       * better but would make these examples less readable.
-     * <p/>
+     * <p>
       * The wrapper will allow data to be collected on the native
       * method call, but now the problem becomes linking up the
       * wrapped method with the native implementation.
@@ -583,7 +585,7 @@
       * which might be:
       * <pre>
       *   Java_somePackage_someClass_foo(JNIEnv* env, jint x)</pre>
-     * <p/>
+     * <p>
       * This function allows the prefix to be specified and the
       * proper resolution to occur.
       * Specifically, when the standard resolution fails, the
@@ -596,29 +598,29 @@
       * <pre>{@code
       *   method(foo) -> nativeImplementation(foo)
       * }</pre>
-     * <p/>
+     * <p>
       * When this fails, the resolution will be retried with
       * the specified prefix prepended to the method name,
       * yielding the correct resolution:
       * <pre>{@code
       *   method(wrapped_foo) -> nativeImplementation(foo)
       * }</pre>
-     * <p/>
+     * <p>
       * For automatic resolution, the JVM will attempt:
       * <pre>{@code
       *   method(wrapped_foo) -> nativeImplementation(wrapped_foo)
       * }</pre>
-     * <p/>
+     * <p>
       * When this fails, the resolution will be retried with
       * the specified prefix deleted from the implementation name,
       * yielding the correct resolution:
       * <pre>{@code
       *   method(wrapped_foo) -> nativeImplementation(foo)
       * }</pre>
-     * <p/>
+     * <p>
       * Note that since the prefix is only used when standard
       * resolution fails, native methods can be wrapped selectively.
-     * <p/>
+     * <p>
       * Since each <code>ClassFileTransformer</code>
       * can do its own transformation of the bytecodes, more
       * than one layer of wrappers may be applied. Thus each