Issue
The generated source code for the parser differs between builds. There are diffs in comments that don't matter much. But there are also different orders between method invocations, in sequences like this:
stream_t3.reset();
stream_ELSE.reset();
This also results in a different order of invocations in bytecode.
Why it matters
This is mainly an issue that compromises reproducible builds and therefore software supply chain security.
For instance, the java compiler tries to avoid non-determinism of generated code, and if detected it is treated as bug.
Examples:
Possible Causes
The use of a hashed data structure in the code generator. Using a LinkedHashMap or TreeMap instead could fix it.
Steps to Reproduce
Use commit 06c44e7 .
- run minimalistic build
mvn clean compile
- copy
target/generated-sources/antlr3/org/stringtemplate/v4/compiler/STParser.java into some tmp folder
- re-run this a few time, use different tmp folder
- diff
STParser.java files
Issue
The generated source code for the parser differs between builds. There are diffs in comments that don't matter much. But there are also different orders between method invocations, in sequences like this:
This also results in a different order of invocations in bytecode.
Why it matters
This is mainly an issue that compromises reproducible builds and therefore software supply chain security.
For instance, the java compiler tries to avoid non-determinism of generated code, and if detected it is treated as bug.
Examples:
Possible Causes
The use of a hashed data structure in the code generator. Using a
LinkedHashMaporTreeMapinstead could fix it.Steps to Reproduce
Use commit 06c44e7 .
mvn clean compiletarget/generated-sources/antlr3/org/stringtemplate/v4/compiler/STParser.javainto some tmp folderSTParser.javafiles