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 due to its logical structure and clear intent. The interface declaration is straightforward, with a concise yet informative Javadoc explaining the behavior and contract deviations. Method declarations are flat, with no nesting, and each method is presented on a single line, making the structure easy to scan. The use of @Override and @CanIgnoreReturnValue annotations is consistent, and the brief comments for each method clarify the intended use when return values are ignored. Imports are organized and limited. The code avoids unnecessary length, with only essential methods and documentation. Reading flow is natural, grouping related read methods logically. Overall, this is an exemplary implementation of a well-documented, minimal interface.
Run 2
The code is highly readable. The structure is logical, clearly defining an interface that extends DataInput. The class-level Javadoc is exemplary, explaining purpose, behavior differences, and implications. Method declarations are concise and follow a consistent pattern. The nesting is minimal, mainly from the interface scope. Each method is on its own line with clear @Override annotations, and the use of @CanIgnoreReturnValue with brief comments directly explains intent for each method. Reading flow is natural, starting with a thorough overview, then simple read methods, followed by more specialized ones. Minor deductions: the comments on skipBytes and readLine could be slightly more formal, but this does not significantly impact readability. Overall, it is very clear, maintainable, and well-documented.
Run 3
The code is highly readable due to its clear, logical structure as a simple interface extending DataInput. It has almost no nesting, with each method declared on a single flat level. Intent is well-documented via the class-level Javadoc (explaining the IOException contract difference) and concise per-method @CanIgnoreReturnValue comments clarifying usage. Code length is minimal—each method signature is only one line and avoids unnecessary boilerplate. Action granularity is excellent: one annotation, one comment, and one method declaration per line, maintaining natural top-to-bottom reading flow. Minor deductions are for the import of Nullable (which may be unnecessary) and the slightly verbose Javadoc warning paragraph, but these do not meaningfully hinder readability.
Run 1
Code Structure: The interface is logically organized, with related read operations grouped consistently. Nesting: The code is flat, with no nested control flow. Clarity of intent: Familiar DataInput method names and clear documentation explain the interface's purpose, unchecked failure behavior, and return-value annotations. Code length: The declarations are concise; repeated annotations and comments add some visual bulk but convey useful contract details. Action granularity: Each method declaration occupies its own line, with annotations clearly associated with it. Reading flow: Consistent spacing and ordering make the interface easy to scan. Minor readability limitations include abbreviated parameter names and repetitive 'to skip some bytes' comments.
Run 2
Code Structure: A well-organized interface with consistently formatted method declarations and logical grouping of related reads. Nesting: Flat, with no nested control flow. Clarity of intent: The interface name, standard DataInput method names, and class documentation clearly explain its purpose and exception behavior; comments clarify return-value handling. Code length: Concise for the API provided, though repeated annotations and skip comments add minor visual repetition. Action granularity: Each method declaration occupies its own line, with annotations clearly separated; there are no combined operations. Reading flow: Predictable ordering and blank lines make scanning easy. Minor weaknesses include abbreviated parameter names and limited spacing around the package and imports.
Run 3
Code Structure: The interface is logically organized, grouping bulk reads, skipping, and typed reads consistently. Nesting: Completely flat apart from the interface scope. Clarity of intent: The Javadoc clearly explains the purpose and exception-contract difference; annotations and comments clarify return-value handling. Code length: Concise for the API exposed, with necessary method declarations and modest annotation repetition. Action granularity: Each declaration occupies its own line, with no bundled operations. Reading flow: Consistent formatting and spacing make the method list easy to scan. Minor readability weaknesses include terse parameter names (b, off, len, n), repetitive comments, and the lack of separation between the package declaration and imports.