Fix JavaDoc warnings and enforce zero errors in Gradle

gradle/mockito-core/javadoc.gradle

@@ -22,8 +22,6 @@ javadoc {
     // While there's errors the javadoc is still generated without those symbols or links ;
     // for this reason the javadoc output is suppressed and can be reactivated with --info option.
     exclude 'org/mockito/internal'
-    logging.captureStandardError LogLevel.INFO
-    logging.captureStandardOutput LogLevel.INFO // suppress "## warnings" message
 
     options.docTitle = """<h1><a href="org/mockito/Mockito.html">Click to see examples</a>. Mockito ${project.version} API.</h1>"""
     options.windowTitle = "Mockito ${project.version} API"
@@ -41,9 +39,7 @@ javadoc {
     options.noNavBar = false
     options.noTree = false
     options.links = ['https://docs.oracle.com/javase/6/docs/api/',
-                     'http://junit.org/junit4/javadoc/4.12/']
-    options.header("""<em id="mockito-version-header-javadoc7-header"><strong>Mockito ${project.version} API</strong></em>""")
-    options.footer("""<em id="mockito-version-header-javadoc7-footer"><strong>Mockito ${project.version} API</strong></em>""")
+                     'https://junit.org/junit4/javadoc/4.12/']
     options.bottom("""
         <script type="text/javascript" src="{@docRoot}/js/jdk6-project-version-insert.min.js"></script>
         <script type="text/javascript" src="{@docRoot}/js/jquery-1.7.min.js"></script>
@@ -53,16 +49,8 @@ javadoc {
         <script type="text/javascript" src="{@docRoot}/js/index.js" async defer></script>
     """.replaceAll(/\r|\n|[ ]{8}/, ""))
     options.stylesheetFile rootProject.file("src/javadoc/stylesheet.css")
-    options.addStringOption('Xdoclint:none', '-quiet')
-
-    def minorVersion = System.getProperty("java.version") =~ /1.8.0_(\d*)/
-
-    // Since JDK 8 version 121 scripts are not allowed in comments. However,
-    // earlier version throw an error if an unknown option is passed.
-    // Therefore only add this option if the JDK is actually correct.
-    if (minorVersion.size() > 0 && Integer.valueOf(minorVersion[0][1]) >= 121 || JavaVersion.current().isJava9Compatible()) {
-        options.addBooleanOption('-allow-script-in-comments', true)
-    }
+    options.addStringOption('Xwerror', '-quiet')
+    options.addBooleanOption('-allow-script-in-comments', true)
 
     doLast {
         copy {

src/main/java/org/mockito/AdditionalAnswers.java

@@ -31,7 +31,7 @@
  *
  * <p>Currently offer answers that can return the parameter of an invocation at a certain position,
  * along with answers that draw on a strongly typed interface to provide a neater way to write custom answers
- * that either return a value or are void (see answer interfaces in {@link org.mockito.stubbing}).
+ * that either return a value or are void (see answer interfaces in org.mockito.stubbing).
  *
  * <p>See factory methods for more information : {@link #returnsFirstArg}, {@link #returnsSecondArg},
  * {@link #returnsLastArg}, {@link #returnsArgAt}, {@link #answer} and {@link #answerVoid}

src/main/java/org/mockito/ArgumentCaptor.java

@@ -15,7 +15,7 @@
  *
  * <p>
  * Mockito verifies argument values in natural java style: by using an equals() method.
- * This is also the recommended way of matching arguments because it makes tests clean & simple.
+ * This is also the recommended way of matching arguments because it makes tests clean and simple.
  * In some situations though, it is helpful to assert on certain arguments after the actual verification.
  * For example:
  * <pre class="code"><code class="java">

src/main/java/org/mockito/ArgumentMatcher.java

@@ -80,7 +80,7 @@
  * and use a lambda, e.g.:
  *
  * <pre class="code"><code class="java">
- *   verify(mock).addAll(<b>argThat(list -> list.size() == 2)</b>);
+ *   verify(mock).addAll(<b>argThat(list -&gt; list.size() == 2)</b>);
  * </code></pre>
  *
  * <p>

src/main/java/org/mockito/MockSettings.java

@@ -23,12 +23,12 @@
  * <p/>
  * Don't use it too often.
  * Consider writing simple tests that use simple mocks.
- * Repeat after me: simple tests push simple, KISSy, readable & maintainable code.
+ * Repeat after me: simple tests push simple, KISSy, readable and maintainable code.
  * If you cannot write a test in a simple way - refactor the code under test.
  * <p/>
  * Examples of mock settings:
  * <pre class="code"><code class="java">
- *   //Creates mock with different default answer & name
+ *   //Creates mock with different default answer and name
  *   Foo mock = mock(Foo.class, withSettings()
  *                                .defaultAnswer(RETURNS_SMART_NULLS)
  *                                .name("cool mockie")
@@ -51,8 +51,8 @@ public interface MockSettings extends Serializable {
      * Specifies extra interfaces the mock should implement. Might be useful for legacy code or some corner cases.
      * <p>
      * This mysterious feature should be used very occasionally.
-     * The object under test should know exactly its collaborators & dependencies.
-     * If you happen to use it often than please make sure you are really producing simple, clean & readable code.
+     * The object under test should know exactly its collaborators and dependencies.
+     * If you happen to use it often than please make sure you are really producing simple, clean and readable code.
      * <p>
      * Examples:
      * <pre class="code"><code class="java">
@@ -101,7 +101,7 @@ public interface MockSettings extends Serializable {
      * <p>
      * However, there are rare cases when partial mocks come handy:
      * dealing with code you cannot change easily (3rd party interfaces, interim refactoring of legacy code etc.)
-     * However, I wouldn't use partial mocks for new, test-driven & well-designed code.
+     * However, I wouldn't use partial mocks for new, test-driven and well-designed code.
      * <p>
      * Enough warnings about partial mocks, see an example how spiedInstance() works:
      * <pre class="code"><code class="java">