feedback-to-code/mozzarella huggingface dataset:
Repository: mockito/mockito
Issue: Reduce memory consumption of the typical LocationImpl

I recently noticed very heavy memory usage on our testsuite (which is using mockito) so I started profiling.

I eventually found #1313 but that's already being worked on. Also spotted a low hanging fruit: our testsuite is allocating about 6 *million* instances of `LocationImpl`.
It looks like I can't avoid that easily, however each `LocationImpl` also allocates a new `StackTraceFilter`, which can be easily avoided when the default is being applied; sending a PR shortly.

This should save us about 6 million empty and pointless `StackTraceFilter` :)

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/org/mockito/internal/debugging/LocationImpl.java b/src/main/java/org/mockito/internal/debugging/LocationImpl.java
index ce3de04a0a..8561b62d3e 100644
--- a/src/main/java/org/mockito/internal/debugging/LocationImpl.java
+++ b/src/main/java/org/mockito/internal/debugging/LocationImpl.java
@@ -11,11 +11,14 @@
 public class LocationImpl implements Location, Serializable {
 
     private static final long serialVersionUID = -9054861157390980624L;
+    //Limit the amount of objects being created, as this class is heavily instantiated:
+    private static final StackTraceFilter defaultStackTraceFilter = new StackTraceFilter();
+
     private final Throwable stackTraceHolder;
     private final StackTraceFilter stackTraceFilter;
 
     public LocationImpl() {
-        this(new StackTraceFilter());
+        this(defaultStackTraceFilter);
     }
 
     public LocationImpl(StackTraceFilter stackTraceFilter) {
@@ -23,7 +26,7 @@ public LocationImpl(StackTraceFilter stackTraceFilter) {
     }
 
     public LocationImpl(Throwable stackTraceHolder) {
-        this(new StackTraceFilter(), stackTraceHolder);
+        this(defaultStackTraceFilter, stackTraceHolder);
     }
 
     private LocationImpl(StackTraceFilter stackTraceFilter, Throwable stackTraceHolder) {


Test patch:
Repository: mockito/mockito
Issue: ignoreStubs documentation should be updated for strictness
Labels: docs

Driven by #1436, we need to update 'ignoreStubs' docs to include information about Mockito strictness (effectively replaces the need for 'ignoreStubs').

Issue comments:
Thank you for contribution!

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/org/mockito/Mockito.java b/src/main/java/org/mockito/Mockito.java
index 44d6b3e0dd..4471b83b92 100644
--- a/src/main/java/org/mockito/Mockito.java
+++ b/src/main/java/org/mockito/Mockito.java
@@ -2535,7 +2535,10 @@ public static InOrder inOrder(Object... mocks) {
 
     /**
      * Ignores stubbed methods of given mocks for the sake of verification.
-     * Sometimes useful when coupled with <code>verifyNoMoreInteractions()</code> or verification <code>inOrder()</code>.
+     * Please consider using {@link Strictness#STRICT_STUBS} feature which eliminates the need for <code>ignoreStubs()</code>
+     * and provides other benefits.
+     * <p>
+     * <code>ignoreStubs()</code> is sometimes useful when coupled with <code>verifyNoMoreInteractions()</code> or verification <code>inOrder()</code>.
      * Helps avoiding redundant verification of stubbed calls - typically we're not interested in verifying stubs.
      * <p>
      * <b>Warning</b>, <code>ignoreStubs()</code> might lead to overuse of <code>verifyNoMoreInteractions(ignoreStubs(...));</code>
@@ -2591,6 +2594,20 @@ public static InOrder inOrder(Object... mocks) {
      *  inOrder.verify(list).clear();
      *  inOrder.verifyNoMoreInteractions();
      * </code></pre>
+     * Stubbed invocations are automatically verified with {@link Strictness#STRICT_STUBS} feature
+     * and it eliminates the need for <code>ignoreStubs()</code>. Example below uses JUnit Rules:
+     * <pre class="code"><code class="java">
+     *  &#064;Rule public MockitoRule mockito = MockitoJUnit.rule().strictness(Strictness.STRICT_STUBS);
+     *
+     *  List list = mock(List.class);
+     *  when(list.get(0)).thenReturn("foo");
+     *
+     *  list.size();
+     *  verify(list).size();
+     *
+     *  list.get(0); // Automatically verified by STRICT_STUBS
+     *  verifyNoMoreInteractions(list); // No need of ignoreStubs()
+     * </code></pre>
      *
      * @since 1.9.0
      * @param mocks input mocks that will be changed


Test patch:
Repository: mockito/mockito
Issue: Enable Gradle Build cache for faster local builds
Labels: please contribute
build

Let's enable Gradle build cache for faster local builds.

https://docs.gradle.org/current/userguide/build_cache.html

Issue comments:

Pull request review comments:
Great! We don't want local cache on CI.
Why do we need this setting or the next one? Can we rely on Gradle's defaults?
good question, let's rely on defaults for now and adjust them if needed later on.

Patch that resolved the issue:
diff --git a/.gitignore b/.gitignore
index b91f27c74a..9d0c115582 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,6 +14,7 @@ bin/
 
 # Gradle & builds
 build
+build-cache
 target
 out
 .gradle
diff --git a/gradle.properties b/gradle.properties
index 41f55a5303..5970e287bb 100644
--- a/gradle.properties
+++ b/gradle.properties
@@ -1,2 +1,3 @@
 org.gradle.daemon=true
 org.gradle.parallel=true
+org.gradle.caching=true
diff --git a/settings.gradle b/settings.gradle
index 8dd114e648..15bc234122 100644
--- a/settings.gradle
+++ b/settings.gradle
@@ -18,3 +18,9 @@ rootProject.children.each { project ->
 }
 
 enableFeaturePreview('STABLE_PUBLISHING')
+
+buildCache {
+    local {
+        enabled = !System.getenv().containsKey("CI")
+    }
+}


Test patch:
Repository: mockito/mockito
Issue: InjectingAnnotationEngine does an unnecessary loop.
Labels: injection

processInjectMocks method of InjectingAnnotationEngine does unnecessary work. It might call injectMocks several times while it is sufficient to call injectMocks once.

    private void processInjectMocks(final Class<?> clazz, final Object testInstance) {
        Class<?> classContext = clazz;
        while (classContext != Object.class) {
            injectMocks(testInstance);
            classContext = classContext.getSuperclass();
        }
    }

Inside, injectMocks loops classes by himself.

    public void injectMocks(final Object testClassInstance) {
        Class<?> clazz = testClassInstance.getClass();
        Set<Field> mockDependentFields = new HashSet<Field>();
        Set<Object> mocks = newMockSafeHashSet();

        while (clazz != Object.class) {
            new InjectMocksScanner(clazz).addTo(mockDependentFields);
            new MockScanner(testClassInstance, clazz).addPreparedMocks(mocks);
            onInjection(testClassInstance, clazz, mockDependentFields, mocks);
            clazz = clazz.getSuperclass();
        }

        new DefaultInjectionEngine().injectMocksOnFields(mockDependentFields, mocks, testClassInstance);
    }

Why not delete the unnecessary loop?

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/org/mockito/internal/configuration/InjectingAnnotationEngine.java b/src/main/java/org/mockito/internal/configuration/InjectingAnnotationEngine.java
index 6cb5fb123b..20d967d07e 100644
--- a/src/main/java/org/mockito/internal/configuration/InjectingAnnotationEngine.java
+++ b/src/main/java/org/mockito/internal/configuration/InjectingAnnotationEngine.java
@@ -39,15 +39,7 @@ public class InjectingAnnotationEngine implements AnnotationEngine, org.mockito.
      */
     public void process(Class<?> clazz, Object testInstance) {
         processIndependentAnnotations(testInstance.getClass(), testInstance);
-        processInjectMocks(testInstance.getClass(), testInstance);
-    }
-
-    private void processInjectMocks(final Class<?> clazz, final Object testInstance) {
-        Class<?> classContext = clazz;
-        while (classContext != Object.class) {
-            injectMocks(testInstance);
-            classContext = classContext.getSuperclass();
-        }
+        injectMocks(testInstance);
     }
 
     private void processIndependentAnnotations(final Class<?> clazz, final Object testInstance) {


Test patch:
Repository: mockito/mockito
Issue: Gradle javadoc plugin fails with latest JDK 11 release 
Labels: java-11
build

The javadoc plugin fails with a status code 1 on current JVM 11.0.2 releases.

Issue comments:
My machine is still on JVM 11.0.1. Going to have to go through Travis this time around to debug this issue...

Pull request review comments:

Patch that resolved the issue:
diff --git a/build.gradle b/build.gradle
index a047ced6a9..0dac0c72f3 100644
--- a/build.gradle
+++ b/build.gradle
@@ -59,6 +59,12 @@ allprojects { proj ->
         options.warnings = false
         options.encoding = 'UTF-8'
     }
+    tasks.withType(Javadoc) {
+        options.addStringOption('Xdoclint:none', '-quiet')
+        options.addStringOption('encoding', 'UTF-8')
+        options.addStringOption('charSet', 'UTF-8')
+        options.setSource('8')
+    }
     apply plugin: 'checkstyle'
     checkstyle {
        configFile = rootProject.file('config/checkstyle/checkstyle.xml')


Test patch:
Repository: mockito/mockito
Issue: Release build is failing

After the latest Shipkit update, our Travis is failing: https://travis-ci.org/mockito/mockito/jobs/501397895#L1693 It fails with

```
[commit]  2 files changed, 11 insertions(+), 2 deletions(-)
[performRelease]   External process [commit] completed.
[performRelease] [tag] fatal: tag 'v2.24.8' already exists
```

@mstachniuk could you take a look?

Issue comments:
@TimvdLippe it looks like we fixed this one in https://github.com/mockito/shipkit/pull/782.
I can do some local testing and provide a PR for this one soon (shipkit version update).
Thanks for that @epeee Looking forward to that PR.
Thank you guys!

Pull request review comments:

Patch that resolved the issue:
diff --git a/build.gradle b/build.gradle
index c8142db658..4285ff16ff 100644
--- a/build.gradle
+++ b/build.gradle
@@ -11,7 +11,7 @@ buildscript {
         classpath 'net.ltgt.gradle:gradle-errorprone-plugin:0.6'
 
         //Using buildscript.classpath so that we can resolve shipkit from maven local, during local testing
-        classpath 'org.shipkit:shipkit:2.1.3'
+        classpath 'org.shipkit:shipkit:2.1.6'
     }
 }
 
diff --git a/version.properties b/version.properties
index 5c5d37b0ac..19b0042628 100644
--- a/version.properties
+++ b/version.properties
@@ -1,5 +1,5 @@
 #Currently building Mockito version
-version=2.24.8
+version=2.24.9
 
 #Previous version used to generate release notes delta
 previousVersion=2.24.7


Test patch:
Repository: mockito/mockito
Issue: Difference between 'timeout' and 'after' not immediately clear

The first few lines of the JavaDoc for both methods do not exactly specify their difference. From `timeout` you have to jump to `after` where at the end of the JavaDoc the difference is explained.

I think this can be improved. The first sentence in `timeout` could be more specific to highlight the difference directly.

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/org/mockito/Mockito.java b/src/main/java/org/mockito/Mockito.java
index 786b716a51..2f247045a2 100644
--- a/src/main/java/org/mockito/Mockito.java
+++ b/src/main/java/org/mockito/Mockito.java
@@ -2820,14 +2820,13 @@ public static VerificationMode only() {
     }
 
     /**
-     * Verification will be triggered after given amount of millis, allowing testing of async code.
+     * Verification will be triggered over and over until the given amount of millis, allowing testing of async code.
      * Useful when interactions with the mock object did not happened yet.
-     * Extensive use of after() method can be a code smell - there are better ways of testing concurrent code.
+     * Extensive use of {@code timeout()} method can be a code smell - there are better ways of testing concurrent code.
      * <p>
      * See also {@link #after(long)} method for testing async code.
      * Differences between {@code timeout()} and {@code after} are explained in Javadoc for {@link #after(long)}.
-     * <p>
-     * Extensive use of {@code timeout()} method can be a code smell - there are better ways of testing concurrent code.
+     *
      * <pre class="code"><code class="java">
      *   //passes when someMethod() is called no later than within 100 ms
      *   //exits immediately when verification is satisfied (e.g. may not wait full 100 ms)
@@ -2856,7 +2855,7 @@ public static VerificationWithTimeout timeout(long millis) {
     /**
      * Verification will be triggered after given amount of millis, allowing testing of async code.
      * Useful when interactions with the mock object did not happened yet.
-     * Extensive use of after() method can be a code smell - there are better ways of testing concurrent code.
+     * Extensive use of {@code after()} method can be a code smell - there are better ways of testing concurrent code.
      * <p>
      * Not yet implemented to work with InOrder verification.
      * <p>


Test patch:
Repository: mockito/mockito
Issue: Typo in Mockito.java Javadoc: "verification" in wiki link

https://github.com/mockito/mockito/blob/f8581c6e875dc3fb587fe31e85d025ef4d110a3f/src/main/java/org/mockito/Mockito.java#L2579

There's a missing "i" in the wiki link:

```
https://github.com/mockito/mockito/wiki/Greedy-algorithm-of-verfication-InOrder
https://github.com/mockito/mockito/wiki/Greedy-algorithm-of-verification-InOrder
```

Issue comments:
Feel free to send a PR!

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/org/mockito/Mockito.java b/src/main/java/org/mockito/Mockito.java
index 2f247045a2..3c8cdf7478 100644
--- a/src/main/java/org/mockito/Mockito.java
+++ b/src/main/java/org/mockito/Mockito.java
@@ -2576,7 +2576,7 @@ public static Stubber doReturn(Object toBeReturned, Object... toBeReturnedNext)
      * <p>
      * <code>InOrder</code> verification is 'greedy', but you will hardly ever notice it.
      * If you want to find out more, read
-     * <a href="https://github.com/mockito/mockito/wiki/Greedy-algorithm-of-verfication-InOrder">this wiki page</a>.
+     * <a href="https://github.com/mockito/mockito/wiki/Greedy-algorithm-of-verification-InOrder">this wiki page</a>.
      * <p>
      * As of Mockito 1.8.4 you can verifyNoMoreInteractions() in order-sensitive way. Read more: {@link InOrder#verifyNoMoreInteractions()}
      * <p>


Test patch:
Repository: mockito/mockito
Issue: Bintray badge is out of date

The badges in README.md show:
```
maven-central 3.2.0 Download 3.1.13
```
That makes the project looks sloppy, as if the developers forgot to update their downloads. "Download" is actually a link to Bintray, which should be clarified.

Bintray does have version 3.2.0. The old version is shown because the package name in the link is wrong. It should be "mockito", not "mockito-development"

Issue comments:

Pull request review comments:
Same as on the website PR, let's keep this `mockito-development` and fix the bug in Shipkit instead.
OK, I've reverted that change. Sadly, it means that #1839 is not going to be fully fixed by this PR. At least "Download" would become "Bintray", so that users won't expect it to the **the** download link.

Patch that resolved the issue:
diff --git a/README.md b/README.md
index 8d03229ad3..a69f94874a 100644
--- a/README.md
+++ b/README.md
@@ -6,12 +6,14 @@
 
 Most popular mocking framework for Java
 
-[![Build Status](https://travis-ci.org/mockito/mockito.svg?branch=release/3.x)](https://travis-ci.org/mockito/mockito) [![Coverage Status](https://img.shields.io/codecov/c/github/mockito/mockito.svg)](https://codecov.io/github/mockito/mockito) [![MIT License](http://img.shields.io/badge/license-MIT-green.svg) ](https://github.com/mockito/mockito/blob/release/3.x/LICENSE)
-
-[![latest release](https://img.shields.io/badge/release%20notes-3.x-yellow.svg)](https://github.com/mockito/mockito/blob/release/3.x/doc/release-notes/official.md)
-[![Maven Central](https://img.shields.io/maven-central/v/org.mockito/mockito-core.svg)](http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.mockito%22%20AND%20a%3A%22mockito-core%22)
-[![Bintray](https://api.bintray.com/packages/mockito/maven/mockito-development/images/download.svg)](https://bintray.com/mockito/maven)
-[![Javadocs](http://www.javadoc.io/badge/org.mockito/mockito-core.svg?color=red)](http://www.javadoc.io/doc/org.mockito/mockito-core)
+[![Build Status](https://travis-ci.org/mockito/mockito.svg?branch=release/3.x)](https://travis-ci.org/mockito/mockito)
+[![Coverage Status](https://img.shields.io/codecov/c/github/mockito/mockito.svg)](https://codecov.io/github/mockito/mockito)
+[![MIT License](https://img.shields.io/badge/license-MIT-green.svg)](https://github.com/mockito/mockito/blob/release/3.x/LICENSE)
+
+[![Release Notes](https://img.shields.io/badge/release%20notes-3.x-yellow.svg)](https://github.com/mockito/mockito/blob/release/3.x/doc/release-notes/official.md)
+[![Maven Central](https://img.shields.io/maven-central/v/org.mockito/mockito-core.svg)](https://search.maven.org/artifact/org.mockito/mockito-core/)
+[![Bintray](https://img.shields.io/bintray/v/mockito/maven/mockito-development)](https://bintray.com/mockito/maven/mockito/_latestVersion)
+[![Javadoc](https://www.javadoc.io/badge/org.mockito/mockito-core.svg)](https://www.javadoc.io/doc/org.mockito/mockito-core)
 
 
 ## Current version is 3.x


Test patch:
Repository: mockito/mockito
Issue: Update byte-buddy to 1.10.5

Hi,

Byte-buddy had a bug that prevented running tests in IntelliJ due to space in the executable name: https://github.com/raphw/byte-buddy/issues/732 This was fixed in [1.10.5](https://github.com/raphw/byte-buddy/releases/tag/byte-buddy-1.10.5) so it would make sense to update it in Mockito as well.

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/gradle/dependencies.gradle b/gradle/dependencies.gradle
index 0e6b448762..cebf8058cb 100644
--- a/gradle/dependencies.gradle
+++ b/gradle/dependencies.gradle
@@ -4,7 +4,7 @@ ext {
 
 def versions = [:]
 
-versions.bytebuddy = '1.10.3'
+versions.bytebuddy = '1.10.5'
 versions.junitJupiter = '5.4.2'
 versions.errorprone = '2.3.2'
 


Test patch:
Repository: mockito/mockito
Issue: Unbalanced HTML tags in Javadoc of UnnecessaryStubbingException
Labels: please contribute

In the [Javadoc of that class](https://javadoc.io/static/org.mockito/mockito-core/3.3.1/org/mockito/exceptions/misusing/UnnecessaryStubbingException.html), the `<code` is not closed properly. Because of this, the following paragraphs are rendered in monospace font as well.

While here, `effect not` should be `effect of not`.

Issue comments:
Could you send us a PR to fix this?
Wouldn't it be easier if you just added the missing `</code>` and `of`? It's just two words.
Yeah, if you could open a PR to make that change we can fix it 😄 
Closed due to too complicated workflow.
Let's reopen so that someone else can make the PR.

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/org/mockito/exceptions/misusing/UnnecessaryStubbingException.java b/src/main/java/org/mockito/exceptions/misusing/UnnecessaryStubbingException.java
index 2d4605b4f6..6078437038 100644
--- a/src/main/java/org/mockito/exceptions/misusing/UnnecessaryStubbingException.java
+++ b/src/main/java/org/mockito/exceptions/misusing/UnnecessaryStubbingException.java
@@ -33,10 +33,11 @@
  * when(translator.translate("one")).thenReturn("jeden"); // <- stubbing realized during code execution
  * when(translator.translate("two")).thenReturn("dwa"); // <- stubbing never realized
  * ...
+ * </code>
  * </pre>
  * Notice that one of the stubbed methods were never realized in the code under test, during test execution.
  * The stray stubbing might be an oversight of the developer, the artifact of copy-paste
- * or the effect not understanding the test/code.
+ * or the effect of not understanding the test/code.
  * Either way, the developer ends up with unnecessary test code.
  * In order to keep the codebase clean & maintainable it is necessary to remove unnecessary code.
  * Otherwise tests are harder to read and reason about.


Test patch:
Repository: mockito/mockito
Issue: Update dependency to byte buddy version 1.10.13
Labels: please contribute

https://github.com/mockito/mockito/blob/release/3.x/gradle/dependencies.gradle#L7

1.10.13 is available: https://github.com/raphw/byte-buddy/releases/tag/byte-buddy-1.10.13

Issue comments:
Feel free to open a PR with the version bump 😄 

Pull request review comments:

Patch that resolved the issue:
diff --git a/gradle/dependencies.gradle b/gradle/dependencies.gradle
index bda27edc28..2de0a0008d 100644
--- a/gradle/dependencies.gradle
+++ b/gradle/dependencies.gradle
@@ -4,7 +4,7 @@ ext {
 
 def versions = [:]
 
-versions.bytebuddy = '1.10.10'
+versions.bytebuddy = '1.10.13'
 versions.junitJupiter = '5.4.2'
 versions.errorprone = '2.4.0'
 


Test patch:
Repository: mockito/mockito
Issue: README should refer the latest available documentation
Labels: please contribute

**Actual:**
README contains link `latest documentation` 
http://javadoc.io/page/org.mockito/mockito-core/2/org/mockito/Mockito.html 
which redirects to 
https://javadoc.io/static/org.mockito/mockito-core/2.9.0/org/mockito/Mockito.html 
(Note: version is `2.9.0`)

**Expected:**
The link `latest documentation` should point to the latest available documentation 
http://javadoc.io/page/org.mockito/mockito-core/3/org/mockito/Mockito.html
which redirects to 
https://javadoc.io/static/org.mockito/mockito-core/3.4.4/org/mockito/Mockito.html 
at the current moment (Note: version is `3.4.4`).

Issue comments:
Feel free to open a PR :)

Pull request review comments:

Patch that resolved the issue:
diff --git a/README.md b/README.md
index a69f94874a..12b36459aa 100644
--- a/README.md
+++ b/README.md
@@ -27,7 +27,7 @@ The maintainers of org.mockito:mockito-core and thousands of other packages are
 
 ## Development
 
-Mockito [continuously delivers](https://github.com/mockito/mockito/wiki/Continuous-Delivery-Overview) improvements using Shipkit library (http://shipkit.org). See the [latest release notes](https://github.com/mockito/mockito/blob/release/3.x/doc/release-notes/official.md) and [latest documentation](http://javadoc.io/page/org.mockito/mockito-core/2/org/mockito/Mockito.html). Docs in javadoc.io are available 24h after release. Read also about [semantic versioning in Mockito](https://github.com/mockito/mockito/wiki/Semantic-Versioning). **Note: not every version is published to Maven Central.**
+Mockito [continuously delivers](https://github.com/mockito/mockito/wiki/Continuous-Delivery-Overview) improvements using Shipkit library (http://shipkit.org). See the [latest release notes](https://github.com/mockito/mockito/blob/release/3.x/doc/release-notes/official.md) and [latest documentation](http://javadoc.io/page/org.mockito/mockito-core/latest/org/mockito/Mockito.html). Docs in javadoc.io are available 24h after release. Read also about [semantic versioning in Mockito](https://github.com/mockito/mockito/wiki/Semantic-Versioning). **Note: not every version is published to Maven Central.**
 
 Older 1.x and 2.x releases are available in
 [Central Repository](http://search.maven.org/#artifactdetails|org.mockito|mockito-core|1.10.19|jar)


Test patch: