Item-code blobs round-trip through the vendored utils/encoding/Base64 (1,822 lines) via encodeObject/decodeToObject — i.e. Java object serialization of a String (ItemCodeService lines ~93/119/161/166). That's the ADT-136 native-deserialization sink and gross overkill: the payload is just a YAML string.
Goal: store the YAML string as plain Base64 of its UTF-8 bytes (java.util.Base64), drop the native object (de)serialization, and delete most of the vendored Base64.
Why it's not a quick win: existing items.db rows hold Java-serialized blobs, so this needs a one-time read-old/write-new migration with a fallback decoder (try plain Base64 first, fall back to the legacy decodeToObject, re-write in the new format) — touching the same item-code data just migrated to MyBatis. Do it carefully and smoke-test on a live server.
Tracks ADT-136. Follow-up to the ORMlite→MyBatis migration (PAR-282). Not being done in the current rewrite pass by decision.