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
This code is highly readable due to its clear structure and consistent formatting. The interface declaration is well-documented with a Javadoc comment explaining its purpose, behavior, and warning about misuse. Each method override is placed on a separate line with a concise comment where necessary, enhancing clarity of intent. There is no unnecessary nesting, and the code is appropriately concise for an interface declaration. The annotations (@CanIgnoreReturnValue, @Override) are consistently applied, and comments clarify the purpose of each method. The reading flow is natural, with methods grouped logically by type. Minor deductions are due to the repetitive comments, but they serve a clear purpose in this context.
Run 3
The code is highly readable due to its clean, logical structure and clear intent. It is a simple interface extension with method declarations that are flat—no deep nesting. Each method is concise and one action per line, improving scanning and comprehension. The Javadocs provide useful context about behavior and contract differences, and inline comments clarify why return values should not be ignored. Reading flow is natural, following the original DataInput method order. Minor deductions: the interface's length is somewhat driven by many override declarations, but this is inherent to the design and not unnecessarily verbose.
Run 1
Code Structure: A well-organized interface with consistent method declarations and annotations. Nesting: Flat, with no nested logic. Clarity of intent: The Javadoc clearly explains the interface's purpose, exception behavior, and caller responsibilities; method names are familiar and descriptive, though parameter names are terse. Code length: Appropriate for the API, with some repetitive annotations and comments but no unnecessary implementation detail. Action granularity: Each method declaration occupies its own line, with annotations clearly associated with it. Reading flow: Methods follow a natural progression through input operations, supported by consistent spacing. Minor drawbacks include the lack of separation between the package and imports and slightly repetitive skip-related comments.
Run 2
Code Structure: The interface is logically organized, grouping related read operations in a consistent order. Nesting: There is no nested control flow; all declarations are flat. Clarity of intent: The interface name, standard DataInput method names, and class documentation clearly communicate its purpose and exception behavior. Parameter names such as b and off are terse but conventional. Code length: Concise for an interface that redeclares inherited methods without checked exceptions; repeated annotations are justified. Action granularity: Each method declaration occupies its own line, with annotations clearly separated. Reading flow: Consistent spacing and annotation placement make the methods easy to scan. Minor drawbacks include missing separation between the package and imports and repetitive inline comments, but neither significantly impairs readability.
Run 3
Code Structure: A well-organized interface with consistently formatted declarations and logically ordered read operations. Nesting: Completely flat apart from the interface scope. Clarity of intent: The class documentation clearly explains its purpose, exception behavior, and caller responsibilities; method names follow the familiar DataInput API. Code length: Concise for the API exposed, although repeated annotations and comments add slight visual overhead. Action granularity: Each method declaration occupies its own line, with annotations separated clearly. Reading flow: Consistent spacing and predictable declaration patterns make scanning easy. Minor drawbacks include abbreviated parameter names and the absence of spacing between the package declaration, imports, and import groups.