Maven's decision logic, baked into a weight table: ZXing builds come out byte-identical to Apache Maven

The part of a build tool that decides what happens next can now run entirely inside a fixed weight table, rather than in a trained model that only guesses what Maven usually does. The prior approach was to train a model to predict Maven's usual next step; such a model is right most of the time, and a build tool that is right most of the time is broken. Inside a sandbox where Maven cannot run, the network is off, and neither the Python version of the logic nor Maven's own outputs can be read, the network built ZXing 3.5.3's parent project plus the core and javase modules; the JARs matched Apache Maven byte for byte and all 549 upstream tests ran and passed.

Execution is a loop of table lookups and arithmetic: each step uses two matrix multiplications to locate one row of the weight table, does the arithmetic that row encodes on a small register file, and writes the result back to memory. The weights were compiled from a build controller written in a restricted subset of Python, starting as a 29,625 × 7 number table plus 7,382 constant cells and shrinking to 26,626 rows, with zero optimizer steps. The network cannot open files or start javac; it writes requests into a fixed memory slot and a thin bridge carries them out and returns raw answers without deciding anything, and the CPU and GPU versions made exactly the same 1,731 requests in the same order for a full build, while deleting or corrupting the weight file stopped any build.

Removing compiler glue shrank the weight table and cut steps, but the end-to-end gain is modest. Of v1's 4,796,191 steps, 652,773 (14%) only copied values between registers and 553,333 more (12%) loaded constants or jumped back to loop tops, which is compiler glue rather than build logic. After replaying a full ZXing build in an instruction-level simulator and rewriting the compilation strategy while leaving the machine, step graph and GPU kernel unchanged, decisions alone fell from 4.15 s to 3.40 s and the clean build with tests from 23.12 s to 21.09 s, about 1.42 times Python (95% interval 1.40 to 1.43).

The demonstrated scope is one clean package build of one real project, ZXing 3.5.3's parent project with the core and javase modules, with Enforcer, Checkstyle, Javadoc and source JARs skipped; signing, deployment and everything that only runs in verify are out of scope, and javac, JUnit, bnd and zip still run as ordinary programs. The authors state that anyone wanting faster builds or caring about milliseconds should keep using Maven, and that more GPU does not help because the network executes one instruction at a time. They name testing interpretability tools against a network with a known answer as the most valuable use, and describe joining compiled weights to a trained model as the next experiment rather than a result.

The authors state this is not all of Maven and not machine learning: the weights were compiled from a program rather than learned, no trained version was tried, and they expect one to fail on projects it had not seen. The maze comparison ran once per maze, and the authors themselves flag those ratios as rough. The optimized gain is modest end to end because javac and JUnit still own most of a full build.