The previous API was logically incorrect and the only reason that we hadn't uncovered it was because we
only had payloads that had one segment.
Previously we'd write a manifest entry for each segment. Now we return a stream that clients can write into
for the payload. So the API changes to
var writer = new ZipWriter(out);
writer.data("entry one", new byte[] { ... });
try (var out = writer.stream("entry two")) {
var fi = new FileInputStream("...");
fi.transferTo(out);
}
writer.finish(); // write the zip manifest
Also change things so that we can handle streams that don't return all of the bytes requested during
a given read. Previously we assumed that a read would always return all of the bytes that might be available
in a stream.
The previous API was logically incorrect and the only reason that we hadn't uncovered it was because we only had payloads that had one segment.
Previously we'd write a manifest entry for each segment. Now we return a stream that clients can write into for the payload. So the API changes to
Also change things so that we can handle streams that don't return all of the bytes requested during a given read. Previously we assumed that a read would always return all of the bytes that might be available in a stream.
Address https://github.com/opentdf/java-sdk/issues/66