In this release, our assertions on Java 8 types continue to move from the Truth8 class to the main Truth class. This change should not break compatibility for any supported JDK or Android version, even users who test under old versions of Android without API desugaring. Additionally, we will never break binary compatibility, though some users will have to make changes to their source code in order for it to compile against newer versions.
This release is likely to lead to more build failures than 1.3.0 did. However, those failures should be straightforward to fix.
Example build failure
Foo.java:152: error: reference to assertThat is ambiguous
assertThat(repo.findFileWithName("foo")).isNull();
^
both method assertThat(@​org.jspecify.nullness.Nullable Path) in Truth8 and method assertThat(@​org.jspecify.nullness.Nullable Path) in Truth match
Simplest upgrade strategy (if you can update all your code atomically in the same commit as the Truth upgrade)
In the same commit:
Upgrade Truth to 1.4.0.
Replace import static com.google.common.truth.Truth8.assertThat; with import static com.google.common.truth.Truth.assertThat;.
If you use Kotlin, replace import com.google.common.truth.Truth8.assertThat with import com.google.common.truth.Truth.assertThat.
Replace import com.google.common.truth.Truth8; with import com.google.common.truth.Truth;.
again, similarly for Kotlin if needed
Replace remaining references to Truth8 with references to Truth.
For example, replace Truth8.assertThat(optional).isPresent() with Truth.assertThat(optional).isPresent().
If you're feeling lucky, you can try this one-liner for the code updates:
After that process, it is possible that you'll still see build errors from ambiguous usages of assertThat static imports. If so, you can find a workaround in the section about overload ambiguity in the release notes for 1.3.0. Alternatively, you can wait to upgrade until after a future Truth release, which will eliminate the ambiguity by changing the signatures of some Truth.assertThat overloads.
Incremental upgrade strategy
If you have a very large repo or you have other reasons to prefer to upgrade incrementally, you can use the approach that we used inside Google. Roughly, that approach was:
Make the optional changes discussed in the release notes for 1.3.0.
For any remaining calls to Truth8.assertThat, change them to avoid static import.
That is, replace assertThat(optional).isPresent() with Truth8.assertThat(optional).isPresent().
Upgrade Truth to 1.4.0.
Optionally replace references to Truth8 with references to Truth (including restoring static imports if desired), as discussed in section about the simple upgrade strategy above.
Optional additional changes
If you use assertWithMessage(...).about(intStreams()).that(...), expect.about(optionalLongs()).that(...), or similar, you can remove your call to about. This change will never be necessary; it is just a simplification.
This is similar to a previous optional change from 1.3.0, except that 1.3.0 solved this problem for streams and optionals, whereas 1.4.0 solves it for the other Truth8 types.
For help
Please feel welcome to open an issue to report problems or request help.
Changelog
Added the remaining Truth8.assertThat overloads to the main Truth class. (9be8e77, 1f81827)
Added more that overloads to make it possible to write type-specific assertions when using the remaining Java 8 types. (7c65fc6)
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
If you want to rebase/retry this PR, check this box
This PR has been generated by Mend Renovate. View repository job log here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
Release Notes
google/truth (com.google.truth:truth)v1.4.0: 1.4.0
In this release, our assertions on Java 8 types continue to move from the Truth8 class to the main Truth class. This change should not break compatibility for any supported JDK or Android version, even users who test under old versions of Android without API desugaring. Additionally, we will never break binary compatibility, though some users will have to make changes to their source code in order for it to compile against newer versions.
This release is likely to lead to more build failures than 1.3.0 did. However, those failures should be straightforward to fix.
Example build failure
Foo.java:152: error: reference to assertThat is ambiguous assertThat(repo.findFileWithName("foo")).isNull(); ^ both method assertThat(@​org.jspecify.nullness.Nullable Path) in Truth8 and method assertThat(@​org.jspecify.nullness.Nullable Path) in Truth matchSimplest upgrade strategy (if you can update all your code atomically in the same commit as the Truth upgrade)
In the same commit:
If you're feeling lucky, you can try this one-liner for the code updates:
After that process, it is possible that you'll still see build errors from ambiguous usages of assertThat static imports. If so, you can find a workaround in the section about overload ambiguity in the release notes for 1.3.0. Alternatively, you can wait to upgrade until after a future Truth release, which will eliminate the ambiguity by changing the signatures of some Truth.assertThat overloads.
Incremental upgrade strategy
If you have a very large repo or you have other reasons to prefer to upgrade incrementally, you can use the approach that we used inside Google. Roughly, that approach was:
Optional additional changes
For help
Please feel welcome to open an issue to report problems or request help.
Changelog
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate. View repository job log here.