Skip to content

Commit

Permalink
Javadoc
Browse files Browse the repository at this point in the history
Use HTML 'em' tag instead of 'i' tag
  • Loading branch information
garydgregory committed Jul 21, 2024
1 parent 4a73b69 commit 7111a70
Show file tree
Hide file tree
Showing 3 changed files with 10 additions and 10 deletions.
8 changes: 4 additions & 4 deletions src/test/java/org/apache/commons/collections4/BulkTest.java
Original file line number Diff line number Diff line change
Expand Up @@ -22,13 +22,13 @@
/**
* 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.
Expand Down Expand Up @@ -88,7 +88,7 @@
* 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()
Expand Down Expand Up @@ -123,7 +123,7 @@
* 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.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -314,11 +314,11 @@ public Collection<E> getConfirmed() {
/**
* 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")
Expand Down Expand Up @@ -389,7 +389,7 @@ protected int getIterationBehaviour() {
}

/**
* 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
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -94,12 +94,12 @@
* <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>
Expand Down Expand Up @@ -1845,7 +1845,7 @@ public void testValuesRetainAll() {
}

/**
* 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.
*/
Expand Down

0 comments on commit 7111a70

Please sign in to comment.