Tencent/tinker · error · IllegalArgumentException

${argument} too long: ${bytes.length}

Error message

${argument} too long: ${bytes.length}

What it means

TinkerZipEntry validates that entry names and comments fit in the zip format's 16-bit length fields, so it UTF-8-encodes the string and rejects anything longer than 65535 bytes. The check happens in validateStringLength, which is called when setting the entry name or comment. The comment in the source acknowledges the check is conservative: UTF-8 is treated as the worst case, so a string with 65535+ UTF-8 bytes throws even though other encodings might be shorter. The message reports the actual UTF-8 byte count, not the character count.

Source

Thrown at third-party/tinker-ziputils/src/main/java/com/tencent/tinker/ziputils/ziputil/TinkerZipEntry.java:200

        }*/
    }

    private static boolean containsNulByte(byte[] bytes) {
        for (byte b : bytes) {
            if (b == 0) {
                return true;
            }
        }
        return false;
    }

    private static void validateStringLength(String argument, String string) {
        // This check is not perfect: the character encoding is determined when the entry is
        // written out. UTF-8 is probably a worst-case: most alternatives should be single byte per
        // character.
        byte[] bytes = string.getBytes(Charset.forName("UTF-8"));
        if (bytes.length > 0xffff) {
            throw new IllegalArgumentException(argument + " too long: " + bytes.length);
        }
    }

    /**
     * Returns the comment for this {@code ZipEntry}, or {@code null} if there is no comment.
     * If we're reading a zip file using {@code ZipInputStream}, the comment is not available.
     */
    public String getComment() {
        return comment;
    }

    /**
     * Sets the comment for this {@code ZipEntry}.
     * @throws IllegalArgumentException if the comment is >= 64 Ki UTF-8 bytes.
     */
    public void setComment(String comment) {
        if (comment == null) {
            this.comment = null;

View on GitHub (pinned to 1b7ea02c23)

Solutions

1. Truncate or shorten the entry name/comment to under 65535 UTF-8 bytes before constructing or mutating the TinkerZipEntry.
2. If the long value is a path, store a shorter logical name and map the real path in a manifest/sidecar file.
3. If you genuinely need names over 64 KiB, this fork does not support the zip64 name lengths involved — split the data or use a different archive format.

Example fix

// before
byte[] hugeName = new byte[70000];
entry.setName(new String(hugeName, StandardCharsets.UTF_8));

// after
String name = new String(hugeName, StandardCharsets.UTF_8);
if (name.getBytes(StandardCharsets.UTF_8).length > 0xffff) {
    name = name.substring(0, name.length() - (name.getBytes(StandardCharsets.UTF_8).length - 0xffff));
}
entry.setName(name);

private static final int MAX_ZIP_STR_BYTES = 0xffff;

static String fitZipString(String s) {
    if (s == null || s.getBytes(StandardCharsets.UTF_8).length <= MAX_ZIP_STR_BYTES) {
        return s;
    }
    // trim by characters until the UTF-8 encoding fits
    while (s.getBytes(StandardCharsets.UTF_8).length > MAX_ZIP_STR_BYTES) {
        s = s.substring(0, s.length() - 1);
    }
    return s;
}

When it happens

Trigger: Constructing TinkerZipEntry with a very long name, or calling setName/setComment on an entry whose text exceeds 65535 UTF-8 bytes (e.g. a deep Android resource path or a generated comment), then writing it via TinkerZipOutputStream.

Common situations: Repackaging an APK whose resource-relative paths got prefixed with a long base directory; auto-generated entry names (hashes, nested folder trees); copying entries from another archive while appending suffixes to comments or names.

Related errors

• Bad CRC32: ${value}
• Extra data too long: ${data.length}
• Bad method: ${value}
• Bad size: ${value}
• Bad mode: ${mode}

AI-assisted analysis of Tencent/tinker@1b7ea02c23 (2026-08-14). Data as JSON: /api/errors/4b5b1499167c13dc. Report an issue: GitHub.