Mockito.java contains inaccessible links to articles.
The monkeyisland.pl domain is no longer available.

List of inaccessible articles:
http://monkeyisland.pl/2009/01/13/subclass-and-override-vs-partial-mocking-vs-refactoring
http://monkeyisland.pl/2008/07/12/should-i-worry-about-the-unexpected
http://monkeyisland.pl/2008/04/26/asking-and-telling
http://monkeyisland.pl/2009/01/13/subclass-and-override-vs-partial-mocking-vs-refactoring
src/main/java/org/mockito/Mockito.java
src/main/java/org/mockito/Mockito.java
diff --git a/src/main/java/org/mockito/Mockito.java b/src/main/java/org/mockito/Mockito.java
index e2a0ade374..afbe082d9e 100644
--- a/src/main/java/org/mockito/Mockito.java
+++ b/src/main/java/org/mockito/Mockito.java
@@ -207,7 +207,7 @@
  *
  * //Although it is possible to verify a stubbed invocation, usually <b>it's just redundant</b>
  * //If your code cares what get(0) returns, then something else breaks (often even before verify() gets executed).
- * //If your code doesn't care what get(0) returns, then it should not be stubbed. Not convinced? See <a href="http://monkeyisland.pl/2008/04/26/asking-and-telling">here</a>.
+ * //If your code doesn't care what get(0) returns, then it should not be stubbed.
  * verify(mockedList).get(0);
  * </code></pre>
  *
@@ -426,8 +426,7 @@
  * Some users who did a lot of classic, expect-run-verify mocking tend to use <code>verifyNoMoreInteractions()</code> very often, even in every test method.
  * <code>verifyNoMoreInteractions()</code> is not recommended to use in every test method.
  * <code>verifyNoMoreInteractions()</code> is a handy assertion from the interaction testing toolkit. Use it only when it's relevant.
- * Abusing it leads to <strong>overspecified</strong>, <strong>less maintainable</strong> tests. You can find further reading
- * <a href="http://monkeyisland.pl/2008/07/12/should-i-worry-about-the-unexpected/">here</a>.
+ * Abusing it leads to <strong>overspecified</strong>, <strong>less maintainable</strong> tests.
  *
  * <p>
  * See also {@link Mockito#never()} - it is more explicit and
@@ -598,8 +597,7 @@
  * <b>Before the release 1.8</b>, Mockito spies were not real partial mocks.
  * The reason was we thought partial mock is a code smell.
  * At some point we found legitimate use cases for partial mocks
- * (3rd party interfaces, interim refactoring of legacy code, the full article is
- * <a href="http://monkeyisland.pl/2009/01/13/subclass-and-override-vs-partial-mocking-vs-refactoring">here</a>)
+ * (3rd party interfaces, interim refactoring of legacy code).
  * <p>
  *
  * <pre class="code"><code class="java">
@@ -708,8 +706,7 @@
  * <h3 id="16">16. <a class="meaningful_link" href="#partial_mocks" name="partial_mocks">Real partial mocks</a> (Since 1.8.0)</h3>
  *
  *  Finally, after many internal debates & discussions on the mailing list, partial mock support was added to Mockito.
- *  Previously we considered partial mocks as code smells. However, we found a legitimate use case for partial mocks - more reading:
- *  <a href="http://monkeyisland.pl/2009/01/13/subclass-and-override-vs-partial-mocking-vs-refactoring">here</a>
+ *  Previously we considered partial mocks as code smells. However, we found a legitimate use case for partial mocks.
  *  <p>
  *  <b>Before release 1.8</b> <code>spy()</code> was not producing real partial mocks and it was confusing for some users.
  *  Read more about spying: <a href="#13">here</a> or in javadoc for {@link Mockito#spy(Object)} method.
@@ -2070,7 +2067,6 @@ public static <T> T spy(Class<T> classToSpy) {
      * Let's say you've stubbed <code>foo.bar()</code>.
      * If your code cares what <code>foo.bar()</code> returns then something else breaks(often before even <code>verify()</code> gets executed).
      * If your code doesn't care what <code>get(0)</code> returns then it should not be stubbed.
-     * Not convinced? See <a href="http://monkeyisland.pl/2008/04/26/asking-and-telling">here</a>.
      *
      * <p>
      * See examples in javadoc for {@link Mockito} class
@@ -2102,7 +2098,6 @@ public static <T> OngoingStubbing<T> when(T methodCall) {
      * Let's say you've stubbed <code>foo.bar()</code>.
      * If your code cares what <code>foo.bar()</code> returns then something else breaks(often before even <code>verify()</code> gets executed).
      * If your code doesn't care what <code>get(0)</code> returns then it should not be stubbed.
-     * Not convinced? See <a href="http://monkeyisland.pl/2008/04/26/asking-and-telling">here</a>.
      *
      * <p>
      * See examples in javadoc for {@link Mockito} class
@@ -2204,8 +2199,7 @@ public static <T> void clearInvocations(T ... mocks) {
      * Some users who did a lot of classic, expect-run-verify mocking tend to use <code>verifyNoMoreInteractions()</code> very often, even in every test method.
      * <code>verifyNoMoreInteractions()</code> is not recommended to use in every test method.
      * <code>verifyNoMoreInteractions()</code> is a handy assertion from the interaction testing toolkit. Use it only when it's relevant.
-     * Abusing it leads to overspecified, less maintainable tests. You can find further reading
-     * <a href="http://monkeyisland.pl/2008/07/12/should-i-worry-about-the-unexpected/">here</a>.
+     * Abusing it leads to overspecified, less maintainable tests.
      * <p>
      * This method will also detect unverified invocations that occurred before the test method,
      * for example: in <code>setUp()</code>, <code>&#064;Before</code> method or in constructor.
