Follow up to #1357. It'd be nice to always use JDK 22 to build WALA code, while still using --release 11 to generate JDK 11 bytecodes. This blog post gets into why using more recent javac versions is a good idea. I've been running into this as there is a javac bug that was fixed in JDK 22 but hasn't been backported that bites me sometimes when building the util project with NullAway. We'd still want the com.ibm.wala.jdk-version to control which JDK version is used to run tests, with similar logic to #1357. But it'd be nice to "pin" the JDK version used to build WALA at 22 for now, and maybe bump as new JDKs are released. Right now, I can use com.ibm.wala.jdk-version to build with 22 but that also forces tests to run on 22. Also, others may run into the aformentioned javac bug if they don't build with com.ibm.wala.jdk-version set to 22.
Follow up to #1357. It'd be nice to always use JDK 22 to build WALA code, while still using
--release 11
to generate JDK 11 bytecodes. This blog post gets into why using more recentjavac
versions is a good idea. I've been running into this as there is a javac bug that was fixed in JDK 22 but hasn't been backported that bites me sometimes when building theutil
project with NullAway. We'd still want thecom.ibm.wala.jdk-version
to control which JDK version is used to run tests, with similar logic to #1357. But it'd be nice to "pin" the JDK version used to build WALA at 22 for now, and maybe bump as new JDKs are released. Right now, I can usecom.ibm.wala.jdk-version
to build with 22 but that also forces tests to run on 22. Also, others may run into the aformentioned javac bug if they don't build withcom.ibm.wala.jdk-version
set to 22.