package org.opendaylight.mdsal.binding.api;
import com.google.common.util.concurrent.FluentFuture;
-import javax.annotation.CheckReturnValue;
+import edu.umd.cs.findbugs.annotations.CheckReturnValue;
import org.eclipse.jdt.annotation.NonNull;
import org.opendaylight.mdsal.common.api.CommitInfo;
import org.opendaylight.mdsal.common.api.DataValidationFailedException;
* Invoking cancel() on finished transaction (future returned by {@link #commit()} already successfully completed)
* will always fail (return false).
*
- * @return <tt>false</tt> if the task could not be cancelled, typically because it has already completed normally;
- * <tt>true</tt> otherwise
+ * @return {@code false} if the task could not be cancelled, typically because it has already completed normally;
+ * {@code true} otherwise
*/
boolean cancel();
* The effects of a successful commit of data depends on listeners and commit participants that are registered with
* the data broker.
*
- * <h3>Example usage:</h3>
+ * <h4>Example usage:</h4>
* <pre>
* private void doWrite(final int tries) {
* WriteTransaction writeTx = dataBroker.newWriteOnlyTransaction();
* doWrite(2);
* </pre>
*
- * <h2>Failure scenarios</h2>
+ * <h4>Failure scenarios</h4>
*
* <p>
* Transaction may fail because of multiple reasons, such as
* </li>
* </ul>
*
- * <h3>Change compatibility</h3>
+ * <h4>Change compatibility</h4>
* There are several sets of changes which could be considered incompatible between two transactions which are
* derived from same initial state. Rules for conflict detection applies recursively for each subtree level.
*
* Following table shows state changes and failures between two concurrent transactions, which are based on same
* initial state, Tx 1 completes successfully before Tx 2 is committed.
*
- * <table summary="Change compatibility of leaf values">
+ * <table>
+ * <caption>Change compatibility of leaf values</caption>
* <tr>
* <th>Initial state</th>
* <th>Tx 1</th>
* Following table shows state changes and failures between two concurrent transactions, which are based on same
* initial state, Tx 1 completes successfully before Tx 2 is committed.
*
- * <table summary="Change compatibility of containers">
+ * <table>
+ * <caption>Change compatibility of containers</caption>
* <tr>
* <th>Initial state</th>
* <th>Tx 1</th>
* </table>
*
*
- * <h3>Examples of failure scenarios</h3>
+ * <h4>Examples of failure scenarios</h4>
*
- * <h4>Conflict of two transactions</h4>
+ * <h5>Conflict of two transactions</h5>
* This example illustrates two concurrent transactions, which derived from same initial state
* of data tree and proposes conflicting modifications.
*