What causes "Error joining byte arrays" in quarkusio/quarkus?

Look at the wrapped cause (e'getCause()') printed in the stack trace — the RuntimeException is only a wrapper.

quarkusio/quarkus · error · RuntimeException

Error joining byte arrays

Error message

Error joining byte arrays

What it means

Thrown by joinWithNewlines in ParallelCommonsCompressArchiveCreator when concatenating multiple line byte arrays (e.g. path/class-name lists for archive entries) fails at any step, including writing the terminating newline or producing the final byte array. It wraps the underlying exception in a RuntimeException so addFile fails fast during fast-jar packaging.

Source

Thrown at core/deployment/src/main/java/io/quarkus/deployment/pkg/jar/ParallelCommonsCompressArchiveCreator.java:248

        } else {
            scatterZipCreator.addArchiveEntry(zipArchiveEntry, streamSupplier);
        }
    }

    private static byte[] joinWithNewlines(List<byte[]> lines) {
        try (ByteArrayOutputStream out = new ByteArrayOutputStream()) {
            for (byte[] line : lines) {
                if (line.length == 0) {
                    continue;
                }
                out.write(line);
                if (line[line.length - 1] != '\n') {
                    out.write('\n');
                }
            }
            return out.toByteArray();
        } catch (Exception e) {
            throw new RuntimeException("Error joining byte arrays", e);
        }
    }

    private static InputStreamSupplier toInputStreamSupplier(byte[] data) {
        return () -> new ByteArrayInputStream(data);
    }

    private static InputStreamSupplier toInputStreamSupplier(Path path) {
        return () -> {
            try {
                return Files.newInputStream(path);
            } catch (IOException e) {
                throw new UncheckedIOException(e);
            }
        };
    }

    private void normalizeTimestampsAndPermissions(ZipArchiveEntry archiveEntry) {

View on GitHub (pinned to e1c734241f)

Solutions

Look at the wrapped cause (e'getCause()') printed in the stack trace — the RuntimeException is only a wrapper.
Increase Maven memory: MAVEN_OPTS="-Xmx4g" if cause is OutOfMemoryError.
Re-run the build with -Dquarkus.package.type=legacy-jar or fast-jar to rule out packaging-path-specific issues.
If reproducible only after custom code changes to the archive creator, fix the bug in the try block.

Defensive patterns

Strategy: try-catch

Validate before calling

// ensure enough heap for the build
// MAVEN_OPTS="-Xmx4g" ./mvnw clean package
System.out.println(Runtime.getRuntime().maxMemory() / 1024 / 1024 + "MB heap");

Try / catch

try {
    // build with fast-jar packaging
} catch (RuntimeException e) {
    if ("Error joining byte arrays".equals(e.getMessage())) {
        log.error("Jar packaging failed; cause: ", e.getCause());
        // retry with more memory or different package type
    } else throw e;
}

Prevention

Always read the wrapped cause — the message itself carries no detail.
Build with adequate heap (MAVEN_OPTS=-Xmx4g).
Avoid custom modifications to archive creators without tests.
Run mvn clean before retrying builds.

When it happens

Trigger: addFile is called with line data while writing joined bytes to the ByteArrayOutputStream throws, or the byte-array concatenation/loop throws (e.g. OutOfMemoryError wrapped as Exception is unlikely, but any Exception in the try block).

Common situations: Very large application class lists exhausting memory during package builds; disk/IO limits surfaced indirectly; custom modifications to the jar packaging pipeline.

Related errors

AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/aee1720e1490159a. Report an issue: GitHub.