Problem
ScopeUtils.createScope walks $JAVA_HOME/jmods to load WALA's primordial scope. That forces every consumer to have a full JDK with jmods/ and JAVA_HOME set; python-sdk works around it by downloading a 200 MB Temurin JDK on first use. When JAVA_HOME is unset, level 2 silently drops to declared-only edges and the L3/L4 WALA engine is unavailable.
The codeanalyzer-java package on PyPI is stale (2.3.7, a native-image build) while the jar is at 3.0.1.
Scope boundary
In: primordial scope from the running JVM via jrt:/; a pure wheel (codeanalyzer-java) that bundles the jar and depends on jdk4py for the runtime; canjv launcher; release workflow publishes the wheel in lockstep with the jar. Out: python-sdk changes (follow-up), WALA upgrade (1.7+ needs a Java 17 toolchain).
Goals
Caveats and known risks
- WALA's own
com.ibm.wala.core.java11.JrtModule closes its Files.list stream inside try-with-resources before returning it, so iterating fails (source already consumed or closed), in 1.6.7 through 1.8.0. Mitigation: an eager JrtModule in com.ibm.cldk.utils.
- Shrike 1.6.7 rejects class files above version 67 (Java 23). jdk4py 25 ships version 69. Mitigation:
jdk4py>=21,<22 until WALA moves to 1.8.0 (max 70).
- PyPI Trusted Publishing must be configured for this repo/workflow on the
codeanalyzer-java project before the first tagged run, or the publish step fails.
- The wheel installs only
canjv, not codeanalyzer: codeanalyzer-python already claims that console script as a deprecated alias.
Definition of done
- daytrader8
-a 2 under jdk4py 21 with JAVA_HOME unset: edge set equals the jmods baseline (1876 edges; 1391 declared+rta, 375 rta, 110 declared)
- daytrader8
-a 3 --l3-engine wala under jdk4py 21: analysis.json byte-identical to the baseline
- fresh venv,
pip install of the built wheel, canjv -a 2 on daytrader8 produces the same edge set
./gradlew test green apart from the Docker-only integration test
Problem
ScopeUtils.createScopewalks$JAVA_HOME/jmodsto load WALA's primordial scope. That forces every consumer to have a full JDK withjmods/andJAVA_HOMEset; python-sdk works around it by downloading a 200 MB Temurin JDK on first use. WhenJAVA_HOMEis unset, level 2 silently drops to declared-only edges and the L3/L4 WALA engine is unavailable.The
codeanalyzer-javapackage on PyPI is stale (2.3.7, a native-image build) while the jar is at 3.0.1.Scope boundary
In: primordial scope from the running JVM via
jrt:/; a pure wheel (codeanalyzer-java) that bundles the jar and depends onjdk4pyfor the runtime;canjvlauncher; release workflow publishes the wheel in lockstep with the jar. Out: python-sdk changes (follow-up), WALA upgrade (1.7+ needs a Java 17 toolchain).Goals
-a 2and-a 3 --l3-engine walaproduce the same output with noJAVA_HOMEand nojmods/as with a full JDKpip install codeanalyzer-javaworks with no system Java and installscanjvvX.Y.Zpublishes jar, installer and wheel from one workflow, and fails if the tag disagrees withgradle.propertiesCaveats and known risks
com.ibm.wala.core.java11.JrtModulecloses itsFiles.liststream inside try-with-resources before returning it, so iterating fails (source already consumed or closed), in 1.6.7 through 1.8.0. Mitigation: an eagerJrtModuleincom.ibm.cldk.utils.jdk4py>=21,<22until WALA moves to 1.8.0 (max 70).codeanalyzer-javaproject before the first tagged run, or the publish step fails.canjv, notcodeanalyzer: codeanalyzer-python already claims that console script as a deprecated alias.Definition of done
-a 2under jdk4py 21 withJAVA_HOMEunset: edge set equals the jmods baseline (1876 edges; 1391 declared+rta, 375 rta, 110 declared)-a 3 --l3-engine walaunder jdk4py 21:analysis.jsonbyte-identical to the baselinepip installof the built wheel,canjv -a 2on daytrader8 produces the same edge set./gradlew testgreen apart from the Docker-only integration test