Support running on JDK 17 #1281
Conversation
cast/java/test/data/build.gradle.kts
Outdated
|
|
||
| // On JDK 17, deprecation errors in ECJ cannot be disabled when compiling JLex code. So, we disable | ||
| // the ECJ task. | ||
| tasks.named("compileTestJavaUsingEcj") { enabled = false } |
There was a problem hiding this comment.
@liblit this is a JDK 17 specific issue, and I have no idea how to fix it. If you have a better thought here let me know. If you like we can conditionally disable this task only on JDKs with version greater than 11, or something like that.
There was a problem hiding this comment.
I prefer to keep this task enabled on JDKs where we can make it work. There's still some value in the extra checks that ECJ will apply to those builds.
In consideration of your eagerness to move this pull request forward, I will approve it in its current form. However, I would appreciate it if you could follow up with a pull request that restores this task in at least some subset of our builds. Thanks!
There was a problem hiding this comment.
I have limited disabling the task to JDK 17+: bc4a19c
| @@ -23,7 +23,7 @@ org.eclipse.jdt.core.compiler.problem.assertIdentifier=error | |||
| org.eclipse.jdt.core.compiler.problem.autoboxing=ignore | |||
| org.eclipse.jdt.core.compiler.problem.comparingIdentical=error | |||
| org.eclipse.jdt.core.compiler.problem.deadCode=warning | |||
| org.eclipse.jdt.core.compiler.problem.deprecation=error | |||
| org.eclipse.jdt.core.compiler.problem.deprecation=disabled | |||
There was a problem hiding this comment.
Here, somehow ECJ is not getting the release parameter we pass to the Java compiler, so it is reporting warnings for methods deprecated after JDK 11. Maybe there is a way to tell ECJ which Java version we are targeting, and then it won't report such errors?
There was a problem hiding this comment.
I don't know of a way to do that offhand, but I haven't actively investigated. If you think there's a decent chance that I'll find something you missed, feel free to create a new issue as a reminder and assign it to me.
There was a problem hiding this comment.
I think this one is just safe to leave as is. We already compile util with -Werror so any true deprecation issues should cause javac itself to fail.
|
Before landing, we (I) should updated the list of required CI jobs to include the JDK 17 job. |
cast/java/test/data/build.gradle.kts
Outdated
|
|
||
| // On JDK 17, deprecation errors in ECJ cannot be disabled when compiling JLex code. So, we disable | ||
| // the ECJ task. | ||
| tasks.named("compileTestJavaUsingEcj") { enabled = false } |
There was a problem hiding this comment.
I prefer to keep this task enabled on JDKs where we can make it work. There's still some value in the extra checks that ECJ will apply to those builds.
In consideration of your eagerness to move this pull request forward, I will approve it in its current form. However, I would appreciate it if you could follow up with a pull request that restores this task in at least some subset of our builds. Thanks!
| @@ -23,7 +23,7 @@ org.eclipse.jdt.core.compiler.problem.assertIdentifier=error | |||
| org.eclipse.jdt.core.compiler.problem.autoboxing=ignore | |||
| org.eclipse.jdt.core.compiler.problem.comparingIdentical=error | |||
| org.eclipse.jdt.core.compiler.problem.deadCode=warning | |||
| org.eclipse.jdt.core.compiler.problem.deprecation=error | |||
| org.eclipse.jdt.core.compiler.problem.deprecation=disabled | |||
There was a problem hiding this comment.
I don't know of a way to do that offhand, but I haven't actively investigated. If you think there's a decent chance that I'll find something you missed, feel free to create a new issue as a reminder and assign it to me.
With this change, WALA's regression tests pass on JDK 17, and WALA can also load and process some JDK 17 bytecodes. We have not thoroughly tested recent bytecode features and they may still not work, but whatever is exercised by current regression tests seems to be working. Getting things working on JDK 17 required various minor changes.