Javadoc

Use HTML 'em' tag instead of 'i' tag

src/test/java/org/apache/commons/collections4/BulkTest.java

@@ -22,13 +22,13 @@ import junit.framework.TestSuite;
 /**
  * A {@link TestCase} that can define both simple and bulk test methods.
  * <p>
- * A <I>simple test method</I> is the type of test traditionally
+ * A <em>simple test method</em> is the type of test traditionally
  * supplied by {@link TestCase}.  To define a simple test, create a public
  * no-argument method whose name starts with "test".  You can specify
  * the name of simple test in the constructor of {@code BulkTest};
  * a subsequent call to {@link TestCase#run} will run that simple test.
  * <p>
- * A <I>bulk test method</I>, on the other hand, returns a new instance
+ * A <em>bulk test method</em>, on the other hand, returns a new instance
  * of {@code BulkTest}, which can itself define new simple and bulk
  * test methods.  By using the {@link #makeSuite} method, you can
  * automatically create a hierarchical suite of tests and child bulk tests.
@@ -88,7 +88,7 @@ import junit.framework.TestSuite;
  *  simple test methods and no bulk test methods; {@code HashMapTest}
  *  defines one simple test method and two bulk test methods.  When
  *  {@code makeSuite(HashMapTest.class).run} is executed,
- *  <I>five</I> simple test methods will be run, in this order:<P>
+ *  <em>five</em> simple test methods will be run, in this order:<P>
  *
  *  <Ol>
  *  <Li>HashMapTest.testClear()
@@ -123,7 +123,7 @@ import junit.framework.TestSuite;
  *  want to override specific simple tests within a bulk test, use the
  *  {@link #ignoredTests} method.<P>
  *
- *  Note that if you want to use the bulk test methods, you <I>must</I>
+ *  Note that if you want to use the bulk test methods, you <em>must</em>
  *  define your {@code suite()} method to use {@link #makeSuite}.
  *  The ordinary {@link TestSuite} constructor doesn't know how to
  *  interpret bulk test methods.

src/test/java/org/apache/commons/collections4/collection/AbstractCollectionTest.java

@@ -314,11 +314,11 @@ public abstract class AbstractCollectionTest<E> extends AbstractObjectTest {
     /**
      *  Returns an array of objects that are contained in a collection
      *  produced by {@link #makeFullCollection()}.  Every element in the
-     *  returned array <I>must</I> be an element in a full collection.<P>
+     *  returned array <em>must</em> be an element in a full collection.<P>
      *  The default implementation returns a heterogeneous array of
      *  objects with some duplicates. null is added if allowed.
      *  Override if you require specific testing elements.  Note that if you
-     *  override {@link #makeFullCollection()}, you <I>must</I> override
+     *  override {@link #makeFullCollection()}, you <em>must</em> override
      *  this method to reflect the contents of a full collection.
      */
     @SuppressWarnings("unchecked")
@@ -389,7 +389,7 @@ public abstract class AbstractCollectionTest<E> extends AbstractObjectTest {
     }
 
     /**
-     *  Returns an array of elements that are <I>not</I> contained in a
+     *  Returns an array of elements that are <em>not</em> contained in a
      *  full collection.  Every element in the returned array must
      *  not exist in a collection returned by {@link #makeFullCollection()}.
      *  The default implementation returns a heterogeneous array of elements

src/test/java/org/apache/commons/collections4/map/AbstractMapTest.java

@@ -94,12 +94,12 @@ import org.junit.jupiter.api.Test;
  * <p>
  * For tests on modification operations (puts and removes), fixtures are used to verify that that operation results in correct state for the map and its
  * collection views. Basically, the modification is performed against your map implementation, and an identical modification is performed against a
- * <I>confirmed</I> map implementation. A confirmed map implementation is something like <Code>java.util.HashMap</Code>, which is known to conform exactly to
+ * <em>confirmed</em> map implementation. A confirmed map implementation is something like <Code>java.util.HashMap</Code>, which is known to conform exactly to
  * the {@link Map} contract. After the modification takes place on both your map implementation and the confirmed map implementation, the two maps are compared
  * to see if their state is identical. The comparison also compares the collection views to make sure they're still the same.
  * <P>
  *
- * The upshot of all that is that <I>any</I> test that modifies the map in <I>any</I> way will verify that <I>all</I> of the map's state is still correct,
+ * The upshot of all that is that <em>any</em> test that modifies the map in <em>any</em> way will verify that <em>all</em> of the map's state is still correct,
  * including the state of its collection views. So for instance if a key is removed by the map's key set's iterator, then the entry set is checked to make sure
  * the key/value pair no longer appears.
  * <P>
@@ -1845,7 +1845,7 @@ public abstract class AbstractMapTest<K, V> extends AbstractObjectTest {
     }
 
     /**
-     * Verifies that {@link #map} is still equal to {@link #confirmed}. This method checks that the map is equal to the HashMap, <I>and</I> that the map's
+     * Verifies that {@link #map} is still equal to {@link #confirmed}. This method checks that the map is equal to the HashMap, <em>and</em> that the map's
      * collection views are still equal to the HashMap's collection views. An <Code>equals</Code> test is done on the maps and their collection views; their
      * size and <Code>isEmpty</Code> results are compared; their hashCodes are compared; and <Code>containsAll</Code> tests are run on the collection views.
      */