Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump mockito.version from 4.11.0 to 5.1.1 #1402

Merged
merged 1 commit into from
Feb 24, 2023

Conversation

dependabot[bot]
Copy link
Contributor

@dependabot dependabot bot commented on behalf of github Feb 8, 2023

Bumps mockito.version from 4.11.0 to 5.1.1.
Updates mockito-core from 4.11.0 to 5.1.1

Release notes

Sourced from mockito-core's releases.

v5.1.1

Changelog generated by Shipkit Changelog Gradle Plugin

5.1.1

v5.1.0

Changelog generated by Shipkit Changelog Gradle Plugin

5.1.0

v5.0.0

Mockito 5: prepare for future JDK versions

For a while now, we have seen an increase in problems/incompatibilities with recent versions of the JDK due to our usage of JVM-internal API. Most notably, JDK 17 made some changes which are incompatible with the current subclass mockmaker. Therefore, to prepare for the future of JDK, we are making some core changes to ensure Mockito keeps on working.

Switch the default mockmaker to mockito-inline

Back in Mockito 2.7.6, we published a new mockmaker based on the "inline bytecode" principle. This mockmaker creates mocks manipulating bytecode equivalent within the original class such that its method implementations hook into the normal Mockito machinery. As a comparison, the subclass mockmaker generates "real" subclasses for mocks, to mimic the same behavior. While the approaches are similar, the inline mockmaker avoids certain restrictions that the JDK imposes. For example, it does not violate module boundaries (introduced in JDK 9, but more heavily used in JDK 17) and avoids the leaking of the creation of the subclass.

Massive thanks to community member @​reta who implemented this change.

Note: this does not affect mockito-android nor testing on Android.

When should I still be using the subclass mockmaker?

... (truncated)

Commits

Updates mockito-junit-jupiter from 4.11.0 to 5.1.1

Release notes

Sourced from mockito-junit-jupiter's releases.

v5.1.1

Changelog generated by Shipkit Changelog Gradle Plugin

5.1.1

v5.1.0

Changelog generated by Shipkit Changelog Gradle Plugin

5.1.0

v5.0.0

Mockito 5: prepare for future JDK versions

For a while now, we have seen an increase in problems/incompatibilities with recent versions of the JDK due to our usage of JVM-internal API. Most notably, JDK 17 made some changes which are incompatible with the current subclass mockmaker. Therefore, to prepare for the future of JDK, we are making some core changes to ensure Mockito keeps on working.

Switch the default mockmaker to mockito-inline

Back in Mockito 2.7.6, we published a new mockmaker based on the "inline bytecode" principle. This mockmaker creates mocks manipulating bytecode equivalent within the original class such that its method implementations hook into the normal Mockito machinery. As a comparison, the subclass mockmaker generates "real" subclasses for mocks, to mimic the same behavior. While the approaches are similar, the inline mockmaker avoids certain restrictions that the JDK imposes. For example, it does not violate module boundaries (introduced in JDK 9, but more heavily used in JDK 17) and avoids the leaking of the creation of the subclass.

Massive thanks to community member @​reta who implemented this change.

Note: this does not affect mockito-android nor testing on Android.

When should I still be using the subclass mockmaker?

... (truncated)

Commits

Updates mockito-inline from 4.11.0 to 5.1.1

Release notes

Sourced from mockito-inline's releases.

v5.1.1

Changelog generated by Shipkit Changelog Gradle Plugin

5.1.1

v5.1.0

Changelog generated by Shipkit Changelog Gradle Plugin

5.1.0

v5.0.0

Mockito 5: prepare for future JDK versions

For a while now, we have seen an increase in problems/incompatibilities with recent versions of the JDK due to our usage of JVM-internal API. Most notably, JDK 17 made some changes which are incompatible with the current subclass mockmaker. Therefore, to prepare for the future of JDK, we are making some core changes to ensure Mockito keeps on working.

Switch the default mockmaker to mockito-inline

Back in Mockito 2.7.6, we published a new mockmaker based on the "inline bytecode" principle. This mockmaker creates mocks manipulating bytecode equivalent within the original class such that its method implementations hook into the normal Mockito machinery. As a comparison, the subclass mockmaker generates "real" subclasses for mocks, to mimic the same behavior. While the approaches are similar, the inline mockmaker avoids certain restrictions that the JDK imposes. For example, it does not violate module boundaries (introduced in JDK 9, but more heavily used in JDK 17) and avoids the leaking of the creation of the subclass.

Massive thanks to community member @​reta who implemented this change.

Note: this does not affect mockito-android nor testing on Android.

When should I still be using the subclass mockmaker?

... (truncated)

Commits

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

@dependabot dependabot bot force-pushed the dependabot/maven/mockito.version-5.1.1 branch 2 times, most recently from 845f410 to 8241284 Compare February 10, 2023 12:01
@msdousti
Copy link
Collaborator

@dependabot rebase

Bumps `mockito.version` from 4.11.0 to 5.1.1.

Updates `mockito-core` from 4.11.0 to 5.1.1
- [Release notes](https://github.com/mockito/mockito/releases)
- [Commits](mockito/mockito@v4.11.0...v5.1.1)

Updates `mockito-junit-jupiter` from 4.11.0 to 5.1.1
- [Release notes](https://github.com/mockito/mockito/releases)
- [Commits](mockito/mockito@v4.11.0...v5.1.1)

Updates `mockito-inline` from 4.11.0 to 5.1.1
- [Release notes](https://github.com/mockito/mockito/releases)
- [Commits](mockito/mockito@v4.11.0...v5.1.1)

---
updated-dependencies:
- dependency-name: org.mockito:mockito-core
  dependency-type: direct:development
  update-type: version-update:semver-major
- dependency-name: org.mockito:mockito-junit-jupiter
  dependency-type: direct:development
  update-type: version-update:semver-major
- dependency-name: org.mockito:mockito-inline
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot bot force-pushed the dependabot/maven/mockito.version-5.1.1 branch from 8241284 to ca3f322 Compare February 24, 2023 17:21
@msdousti
Copy link
Collaborator

👍

@msdousti msdousti merged commit 825d740 into main Feb 24, 2023
@dependabot dependabot bot deleted the dependabot/maven/mockito.version-5.1.1 branch February 24, 2023 17:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants