← 返回首页
Bug in ByteArrayByteBank · Issue #490 · scijava/scijava-common · GitHub
Skip to content

Navigation Menu

Toggle navigation
Sign in
Appearance settings
Search or jump to...

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Resetting focus

Bug in ByteArrayByteBank #490

New issue
New issue

Description

setBytes method always allocates a new byte array without any necessity. Please see:

public void setBytes(final long startpos, final byte[] bytes, final int offset, final int length) { // ensure we have space checkWritePos(startpos, startpos + length); final int neededCapacity = (int) (size + length); buffer.ensureCapacity(neededCapacity); // copy the data System.arraycopy(bytes, offset, buffer.getArray(), (int) startpos, length); buffer.setSize(neededCapacity); updateSize(startpos + length); }

final int neededCapacity = (int) (size + length);
This is incorrect. The new capacity should depend on the starting position, something like this: startpos + length
This has became a problem in by code:

final byte[] newIFDBytes = oldIFDBytes.clone(); final DataHandle<?> newStream = getBytesHandle(newIFDBytes, littleEndian); ...some writing into newStream...

where

static BytesHandle getBytesHandle(byte[] data, boolean littleEndian) { Objects.requireNonNull(data, "Null data"); final BytesHandle result = new BytesHandle(new BytesLocation(data)); result.setLittleEndian(littleEndian); return result; }

I was hoping that writing to newStream would affect my newIFDBytes array, since I always write within the array's range—I just modified some fields (IFD elements). Unfortunately, the first write to newStream results in a reallocation of the internal byte array. This is bad—after that, I need to read the byte array back from newStream, although this is obviously unnecessary.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Footer

      © 2026 GitHub, Inc.