Source code
package com.google.common.io;
import com.google.common.annotations.GwtIncompatible;
import com.google.common.annotations.J2ktIncompatible;
import com.google.errorprone.annotations.CanIgnoreReturnValue;
import java.io.DataInput;
import java.io.IOException;
import org.jspecify.annotations.Nullable;
/**
* An extension of {@code DataInput} for reading from in-memory byte arrays; its methods offer
* identical functionality but do not throw {@link IOException}.
*
* <p><b>Warning:</b> The caller is responsible for not attempting to read past the end of the
* array. If any method encounters the end of the array prematurely, it throws {@link
* IllegalStateException} to signify <i>programmer error</i>. This behavior is a technical violation
* of the supertype's contract, which specifies a checked exception.
*
* @author Kevin Bourrillion
* @since 1.0
*/
@J2ktIncompatible
@GwtIncompatible
public interface ByteArrayDataInput extends DataInput {
@Override
void readFully(byte[] b);
@Override
void readFully(byte[] b, int off, int len);
// not guaranteed to skip n bytes so result should NOT be ignored
// use ByteStreams.skipFully or one of the read methods instead
@Override
int skipBytes(int n);
@CanIgnoreReturnValue // to skip a byte
@Override
boolean readBoolean();
@CanIgnoreReturnValue // to skip a byte
@Override
byte readByte();
@CanIgnoreReturnValue // to skip a byte
@Override
int readUnsignedByte();
@CanIgnoreReturnValue // to skip some bytes
@Override
short readShort();
@CanIgnoreReturnValue // to skip some bytes
@Override
int readUnsignedShort();
@CanIgnoreReturnValue // to skip some bytes
@Override
char readChar();
@CanIgnoreReturnValue // to skip some bytes
@Override
int readInt();
@CanIgnoreReturnValue // to skip some bytes
@Override
long readLong();
@CanIgnoreReturnValue // to skip some bytes
@Override
float readFloat();
@CanIgnoreReturnValue // to skip some bytes
@Override
double readDouble();
@CanIgnoreReturnValue // to skip a line
@Override
@Nullable String readLine();
@CanIgnoreReturnValue // to skip a field
@Override
String readUTF();
}
Run 1
The code is highly readable. It clearly documents the interface's purpose, its deviation from the DataInput contract, and the rationale for @CanIgnoreReturnValue annotations on each method. The structure is logical: imports, Javadoc, interface declaration, then method overrides grouped with consistent comments. Nesting is minimal—only package and interface-level. Clarity of intent is strong, especially with the warning about IllegalStateException and the guidance on skipBytes. Code length is appropriate; the repetitive annotations are concise and informative. Each method declaration is on a single line, maintaining one-action-per-line granularity. Reading flow is natural and consistent, making it easy to scan method signatures and understand each one's purpose. Minor deductions: some readers might find the repeated inline comments slightly verbose, but they serve an explicit purpose here.
Run 2
The code is highly readable due to its clear structure and purpose. It is well-organized with a logical grouping of imports, a descriptive Javadoc explaining the contract deviation, and a flat, consistent method list. Each method is concise, with one action per line, and the repeated @CanIgnoreReturnValue annotations with comments clarify intent for skipping data. Nesting is minimal, and the reading flow is natural. Minor deductions include verbosity from repeated annotations and slight comment redundancy, but overall it is excellent.
Run 3
The code is highly readable. Structure is clear and logical for an interface extending DataInput, with well-organized imports and Javadoc. Nesting is non-existent (flat). Intent is explicitly documented, including the important deviation from the contract regarding exceptions. Code length is minimal and appropriate, avoiding unnecessary implementation details. Action granularity is one declaration per line, aided by repeated @CanIgnoreReturnValue annotations with concise comments explaining the rationale for skipping return values. Reading flow is natural, grouping related overrides together. Minor deductions: the interface is somewhat verbose due to repeated annotations and comments, and the lack of blank lines between method groups could slightly improve visual separation, but overall readability is excellent.
Run 1
Code Structure: A logically organized interface with consistent method declarations and annotations. Nesting: Flat, with no nested control flow. Clarity of intent: The Javadoc clearly explains the interface's purpose, exception behavior, and caller responsibilities; standard DataInput method names are recognizable. Code length: Appropriate for the interface, although repeated annotations and skip comments add minor visual repetition. Action granularity: Each method declaration occupies its own line, with annotations clearly associated with it. Reading flow: Consistent spacing and ordering make scanning natural. Minor drawbacks include abbreviated parameter names and the lack of separation between the package declaration and imports.
Run 2
Code Structure: A well-organized interface with consistently formatted method declarations and related operations grouped naturally. Nesting: Flat, with no nested control flow. Clarity of intent: The interface name, familiar DataInput methods, and documentation clearly explain its purpose and exception behavior; abbreviated parameters such as b and off are minor weaknesses. Code length: Concise for the API it defines; repeated annotations and comments add some visual repetition but communicate useful contracts. Action granularity: Each declaration occupies its own line, with annotations clearly associated with individual methods. Reading flow: Proceeds naturally from the interface contract through bulk reads, skipping, primitive reads, and string reads. Minor spacing omissions around the package and imports slightly reduce visual separation.
Run 3
Code Structure: A well-organized interface with related read methods grouped logically and consistent annotation placement. Nesting: Completely flat apart from the interface scope, making scanning easy. Clarity of intent: The documentation clearly explains the purpose, exception behavior, and caller responsibilities; standard method names communicate operations well, though abbreviated parameter names are less descriptive. Code length: Concise for the API it defines; repeated annotations and comments add some visual bulk but convey useful contracts. Action granularity: Each method declaration occupies its own line, with no combined operations. Reading flow: Natural progression from bulk reads and skipping to primitive reads and strings, supported by consistent spacing. Minor formatting issues, such as the lack of separation between the package and imports, slightly reduce polish.