Skip to content

The Java byte-vector harness is rebuilt from scratch by every agent that needs test vectors #970

Description

@andrewgazelka

Three slices of the 26.2 protocol port so far (tests/item.rs, and now tests/configuration.rs and tests/play_login.rs in #968) have each stood up the same Java harness to print real encoder bytes, and none of them is committed. The recipe is identical every time:

unzip -q "$JAR" 'META-INF/versions/*/server-*.jar' -d bundle
unzip -q "$JAR" 'META-INF/libraries/*' -d libs
CP="$(find bundle -name 'server-*.jar'):$(find libs -name '*.jar' | tr '\n' :)"
javac -cp "$CP" -d out Harness.java && java -cp "$CP:out" Harness

plus SharedConstants.tryDetectVersion(); Bootstrap.bootStrap(); at the top of main, without which the first touch of BuiltInRegistries throws IllegalArgumentException: Not bootstrapped.

Rediscovering that costs 15-30 minutes each time, and it means the vectors in the tests cannot be regenerated after a protocol bump without rewriting the harness.

Suggested fix: a minecraftHarness derivation in nix/minecraft-data.nix that assembles the classpath from the pinned jar, plus a committed Harness.java per test module (or one with a subcommand). nix run .#minecraft-vectors would then reprint every vector on demand, and a bump would show up as a diff in the printed hex rather than as silently stale fixtures.

Related: #964 (the decompiled set is too narrow for the same reason -- every slice re-runs cfr by hand).

Filed by Claude while implementing #968.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions