Allow projects which don't use jdk-15 to resolve latest nullaway #2400
Conversation
Generate changelog in
|
gradle-baseline-java/src/main/groovy/com/palantir/baseline/plugins/BaselineNullAway.java
Outdated
Show resolved
Hide resolved
…gins/BaselineNullAway.java
gradle-baseline-java/src/main/groovy/com/palantir/baseline/plugins/BaselineNullAway.java
Outdated
Show resolved
Hide resolved
…gins/BaselineNullAway.java
| project.getDependencies().addProvider("errorprone", project.provider(() -> { | ||
| // Cannot upgrade dependencies in this case because newer nullaway/checkerframework | ||
| // are not compatible with java 15, but fully support jdk11 and jdk17. | ||
| return anyProjectUsesJava15(project) ? null : dep; |
There was a problem hiding this comment.
I wonder if this should be the other way around? Per default, we use the latest versions but downgrade to the old compatible version when using j15? That way, j15 is the special case and usage of this hack will phase out naturally once projects roll to j17 (plus excavator will continue to update our used versions)?
There was a problem hiding this comment.
How would you suggest doing that? Part of the issue is that it would bump errorprone deps as well to a version that’s no longer compatible with jdk15. Gcv makes upgrades much easier than downgrades :-/
There was a problem hiding this comment.
Hmm yeah, I was thinking of using resolutionStrategy.force("java-15-dep-coordinate") for all deps that we need to pin to a specific version when using j15. But yeah, we would have to enumerate all the error-prone deps that are also not compatible and this might cause issues when other deps depend on them.
There was a problem hiding this comment.
Hmm yeah, this is becoming more complicated. I guess its fine to put this in for now, given that jdk 15 is EOL soon and we can remove the special casing.
| // the current latest version. | ||
| "org.checkerframework:dataflow-errorprone:3.25.0", | ||
| "org.checkerframework:dataflow-nullaway:3.25.0", | ||
| "org.checkerframework:checker-qual:3.25.0"); |
There was a problem hiding this comment.
We should probably also move nullaway and checkerframework to this section in versions.props to prevent excavator updating it directly:
gradle-baseline/versions.props
Lines 42 to 48 in c1552fa
There was a problem hiding this comment.
I could go either way, we do want to upgrade it eventually, and our test coverage will prevent version-bumps from going through (jdk-15 nullaway integration test won't work!)
There was a problem hiding this comment.
Ah nice, just saw that you added regression tests in #2389
There was a problem hiding this comment.
Baseline-java-versions is super helpful for this style of testing :-]
|
Released 4.174.0 |
###### _excavator_ is a bot for automating changes across repositories. Changes produced by the roomba/latest-baseline-oss check. # Release Notes ## 4.174.0 | Type | Description | Link | | ---- | ----------- | ---- | | Improvement | Allow projects which don't use jdk-15 to resolve latest nullaway | palantir/gradle-baseline#2400 | ## 4.175.0 | Type | Description | Link | | ---- | ----------- | ---- | | Fix | Fix GitHub issues navigation Idea config | palantir/gradle-baseline#2403 | ## 4.176.0 | Type | Description | Link | | ---- | ----------- | ---- | | Improvement | Error-prone is enabled in idea for uniformity with CLI compilation | palantir/gradle-baseline#2405 | ## 4.177.0 | Type | Description | Link | | ---- | ----------- | ---- | | Fix | baseline-immutables adds required exports to the java compiler for compatibility with jdk-17+ | palantir/gradle-baseline#2406 | ## 4.178.0 | Type | Description | Link | | ---- | ----------- | ---- | | Fix | Refaster compilation uses exports matching error-prone compilation | palantir/gradle-baseline#2407 | To enable or disable this check, please contact the maintainers of Excavator.
Before this PR
Crashes due to bugs resolved in newer nullaway releases
After this PR
==COMMIT_MSG==
Allow projects which don't use jdk-15 to resolve latest nullaway
==COMMIT_MSG==
Possible downsides?
Bit of a hack, but likely better than alternatives?