Java I/O API and Securing Applications practice questions

Read the entire file into a byte array using Files.readAllBytes()

Why wrong: This loads the entire file into memory, which is not memory-efficient for large files.

Use a FileReader wrapped in a BufferedReader to read lines

Why wrong: FileReader is for character data, not binary files, and still holds data in memory.

Use a RandomAccessFile to read the file in segments

Why wrong: RandomAccessFile is not memory-efficient and is more complex; BufferedInputStream is simpler and adequate.

Call flush() after every write operation

Why wrong: Flush only ensures data is sent to the OS, but doesn't guarantee atomicity or cleanup on crash.

Delete the file manually in a finally block

Why wrong: If the JVM crashes abruptly, the finally block may not execute, leaving the file.

Use a FileLock to prevent concurrent access

Why wrong: FileLock prevents concurrent access but does not prevent data residue after a crash.

Read the file from disk every time it is accessed using Files.newInputStream()

Why wrong: Reading on every access causes excessive I/O, especially if the file is accessed frequently.

Periodically check the file's lastModified timestamp using File.lastModified() and reload if changed

Why wrong: Polling still involves frequent I/O and timestamps may have limited granularity.

Read the file once at startup and cache the content in memory

Why wrong: This ignores updates, leading to stale data.

BufferedWriter

Why wrong: BufferedWriter does not provide encoding control; it wraps a Writer.

FileWriter

Why wrong: FileWriter uses default encoding, cannot specify UTF-8.

PrintWriter with default constructor

Why wrong: PrintWriter with File parameter uses default encoding.

Use FileInputStream without any additional configuration

Why wrong: If a security manager is enabled, it may deny access without explicit permission.

Use java.net.URL to access the file via file:// protocol

Why wrong: URL still requires permission and may not bypass security restrictions.

Set the file readable flag using File.setReadable(true)

Why wrong: This changes file system permissions, not Java security policy.

Ensure each thread has its own copy of the file handle

Why wrong: Thread safety does not prevent resource leaks.

Call close() on each stream in a separate try-catch block

Why wrong: This is error-prone and can lead to leaks if an exception occurs before close.

Use FileLock to prevent concurrent access

Why wrong: FileLock prevents conflicts but does not handle resource cleanup.

Classes in java.nio.file are thread-safe by default

Why wrong: Thread safety is not guaranteed by default; external synchronization may be needed.

The java.io package includes the Path interface

Why wrong: Path is in java.nio.file, not java.io.

The java.nio.file package is deprecated in favor of java.io

Why wrong: NIO.2 is the modern API and not deprecated.

Files.copy(source, target, StandardCopyOption.COPY_ATTRIBUTES)

Why wrong: Files.copy does not copy directories recursively.

Use Files.walk() and then Files.copy() for each entry

Why wrong: Files.walk returns a stream; using Files.copy on directories fails.

Use FileUtils.copyDirectory from Apache Commons IO

Why wrong: This is not part of standard Java SE; the question expects standard API.

Enabling the security manager is required for all Java applications.

Why wrong: Security manager is optional; many applications run without it.

The Java Cryptography Extension (JCE) is deprecated and should not be used.

Why wrong: JCE is still part of Java SE and not deprecated.

Using code signing guarantees that the application is secure.

Why wrong: Code signing verifies origin but does not enforce security policy.

String content = new FileReader("file.txt").readString();

Why wrong: FileReader does not have readString() method.

String content = Files.readAllLines(Path.of("file.txt"));

Why wrong: readAllLines returns List<String>, not String.

All resources must be of the same type.

Why wrong: They can be of different types.

Multiple resources must be separated by commas.

Why wrong: They are separated by semicolons, not commas.

The resource must implement the Closeable interface.

Why wrong: It must implement AutoCloseable, which Closeable extends, but AutoCloseable is sufficient.

Better performance for all I/O operations compared to java.io.

Why wrong: Performance gains vary; not all operations are faster.

Automatic file compression when writing.

Why wrong: Compression is not built-in; it requires additional libraries.

Increase the thread pool size to handle more concurrent writes.

Why wrong: More threads may increase contention and locking issues.

Use FileChannel with FileLock to synchronize access.

Why wrong: FileLock is for cross-process locking, not needed here, and can cause contention.

Write to local temporary files and then copy to the network drive.

Why wrong: While this may reduce network contention, it does not address the stream closure issue.

Wrap the FileInputStream in a try-with-resources and catch Exception to handle missing file.

Why wrong: Catching Exception is too broad and may hide other issues.

Catch FileNotFoundException inside the try block and set default values.

Why wrong: FileNotFoundException is specific, but it's better to check existence first.

Use File.exists() to check file existence before opening the stream, and if absent, log a warning and use defaults.

Why wrong: File.exists() is outdated; Files.exists() is preferred.

The serialVersionUID must be explicitly declared in every serializable class.

Why wrong: If not declared, Java computes one automatically.

A class that implements Externalizable does not need to implement Serializable.

Why wrong: Externalizable extends Serializable.

Fields marked as transient are serialized by default.

Why wrong: Transient fields are excluded from serialization.

The application codebase URL in the policy file is incorrect.

Why wrong: It's already granted, so likely correct.

The file path is relative and needs to be resolved against user.dir.

Why wrong: Path is absolute, so no resolution needed.

The policy file is not being loaded because the JVM was not started with -Djava.security.policy.

Why wrong: The policy can be specified via security properties file as well.

java.io.Console can be used to read from and write to the standard streams of the JVM.

Why wrong: Console is for interacting with the system console, not general streams.

java.io.FileInputStream supports the mark and reset methods.

Why wrong: FileInputStream does not support mark/reset; BufferedInputStream does.

java.nio.file.Path is a class that represents a file path.

Why wrong: Path is an interface, not a class.

Encrypt the file using AES and decrypt it in the application.

Why wrong: Encryption protects confidentiality, not integrity; a corrupted encrypted file may still decrypt to garbage.

Set the file permissions to read-only for the application user.

Why wrong: Permissions can be bypassed by a privileged user or if the attacker gains the same user context.

Store the file in a ZIP archive with a checksum.

Why wrong: Checksums without a keyed hash are easily forged; an attacker can recompute the checksum after modifying.