Level-up challenge · CSCD210

One program that writes a file and reads it back into an array

You have finished the catch-up path and you want to write one program that makes a file and then reads it back the way a lab will ask you to.

Unlocked at the end of: Arrays and file I/O, from zero, after the room count-allocate-fill. Room 15 closes the path. After it you have written a file, opened it, read it to the end, and built the count pass and the fill pass yourself, which is exactly the program this challenge asks for.

Outcomes this shows6Inputs it is run on4Timeabout 60 minutesDifficulty3 of 3

What this shows you can do

Each line below is one outcome, written the way the course records it. A program that does the whole task shows all of them at once.

Student can construct a PrintStream over a File, declare or catch the FileNotFoundException the constructor throws, write output with println/printf, and close() the stream to flush buffered bytes.
In this program: Everything the program reports comes back out of the file it wrote, so a program that does not construct the stream, does not declare the exception, or writes nothing produces no report at all.
Not shown by a run:"close() the stream to flush buffered bytes". Removing the close from the writing method changed no line of any check, because PrintStream(File) wraps a FileOutputStream with no byte buffer of its own and the bytes reach the operating system as each println runs. The guarantee still needs the close and the spec still asks for it, and a run is not what shows it.
Student can construct a Scanner over a file using the two-step idiom new Scanner(new File(filename)), declare or catch the FileNotFoundException the constructor throws, and close the Scanner to release the file handle when finished.
In this program: Measured: replacing the two-step idiom with new Scanner(filename) in the counting pass reports zero readings and then ends with ArrayIndexOutOfBoundsException, because the scanner reads the characters of the file name instead of the file.
Not shown by a run:"close the Scanner to release the file handle when finished". A comparison of what a program prints cannot see a close.
Student can import java.io.FileNotFoundException, declare it with throws on every method that constructs a Scanner on a File, distinguish it from FileSystemNotFoundException in java.nio.file, and explain why a pre-check (e.g., exists() or canRead()) does not remove the declaration requirement.
In this program: Three of the four required headers already carry the line, and main calls all three. The header of main is not given, so the program does not compile until the student carries the line up to it or handles it there.
Not shown by a run:"distinguish it from FileSystemNotFoundException" and "explain why a pre-check does not remove the declaration requirement". Both of those are said. What a run shows is that the import and the declarations are right, because nothing compiles otherwise.
Student can write a while (sc.hasNextLine()) loop to read every line of a file, recognize the guard-and-read pairing, and adapt the pattern for counting lines (Pass 1 of count-allocate-fill) and for skipping a header before the loop.
In this program: The file has a header line and then one reading per line, so the counting pass has to skip before the loop and pair one guard with one read inside it. Measured: a loop that reads in the guard and again in the body counts half the lines, or ends with NoSuchElementException when the count left is odd.
Student can produce a Pass-1 counting method that takes a filename, opens a fresh Scanner, walks to EOF using a hasNextLine (or hasNextX) guard, increments a counter while discarding the read value, closes the Scanner, and returns the count.
In this program: The first line of the report is the count this method returns, and the four checks have four different counts, so a count that comes from anywhere else matches at most one of them.
Not shown by a run:"closes the Scanner". Not visible in output, the same limit as the Scanner leaf above.
Student can produce a Pass-2 method that takes a filename and a count, opens a fresh Scanner, allocates an array of exactly count slots, fills it with a counted for loop using the appropriate typed read, closes the Scanner, and returns the array.
In this program: The report prints the array's own slot count and its first and last values, so an array allocated larger than the count shows a wrong slot count and a last value of zero.
Not shown by a run:"closes the Scanner", as above.

What to build

Write one program named ReadingsFile.

It reads from standard input. The first number is how many readings follow. Each reading after that is a whole number, and there is at least one.

The program does three things, in order.

First it writes a file named readings.txt in the folder it is running in. The first line of that file is the single word readings. Every line after that is one reading, in the order they arrived.

Then it reads that file back twice. The first pass counts how many readings the file holds, which is every line after the header. The second pass builds an int[] with exactly that many slots and fills it with the readings from the file. Each pass opens the file for itself.

Then it prints five lines, in this order, with the labels spelled exactly as shown here:

readings in file
slots
first
last
sum

Each line is the label, a colon, one space, and the value. Print nothing else, and print no prompt. Nothing in the output names the folder the program ran in.

Every method that opens a file carries throws FileNotFoundException. Three of the four headers below already have it. Java will tell you if another method needs it too.

The rest of the program is yours to shape.

Write these methods with these headers

public static void writeReadings(final String filename, final int[] xs) throws FileNotFoundException
public static int countReadings(final String filename) throws FileNotFoundException
public static int[] readReadings(final String filename, final int count) throws FileNotFoundException
public static int sum(final int[] xs)

One worked example

The first of the inputs, with what the program prints for it.

Five readings, all positive

The count in the report has to come from the file rather than from standard input, which is what the second and third lines of the report separate.

Input

Output

readings in file: 5
slots: 5
first: 71
last: 69
sum: 348

How your program is checked

Your program is run once for each input and its output is compared with what is shown. The worked example above is the first of them. You can run every one of them yourself before you hand anything in.

One reading

The smallest file the spec allows, one header line and one reading, where a counting pass that includes the header is off by a factor of two rather than by a little.

Input

1
40

Output

readings in file: 1
slots: 1
first: 40
last: 40
sum: 40

Eight readings, mixed signs, with a repeated value

Negative numbers are written and read back as tokens, so this is the check that a minus sign survives the round trip through the file.

Input

Output

readings in file: 8
slots: 8
first: -3
last: 7
sum: 54

Three readings, all negative

A third count, so a program that returns a fixed number from the counting pass cannot pass more than one check.

Input

3
-12
-7
-25

Output

readings in file: 3
slots: 3
first: -12
last: -25
sum: -44

What to watch for

Each one is copied from the notes for the rooms this challenge draws on, with what a run shows when it happens.

new Scanner(filename) instead of new Scanner(new File(filename))
What a run shows: The report says zero readings and zero slots, and then the run ends with ArrayIndexOutOfBoundsException on the line that asks for the first value.
omitting throws FileNotFoundException after writing a runtime check
What a run shows: Nothing runs. The compiler stops at the line that opens the file.
importing java.nio.file.FileSystemNotFoundException instead of java.io.FileNotFoundException
What a run shows: Nothing runs. The wrong import satisfies nothing, so the compiler still asks for the exception the constructor actually throws.
reading inside the guard and inside the body (double-read)
What a run shows: The count comes out at half the readings when the number left is even, and the run ends with NoSuchElementException when it is odd.
omitting sc.nextLine() inside the loop body
What a run shows: The run does not end on its own and the sandbox stops it at the CPU limit, so there is no output to compare.
counting before the header skip
What a run shows: The count is one too high, so the filling pass asks the file for one more reading than it holds and the run ends with NoSuchElementException before anything is printed.
forgetting to skip the header in Pass 2
What a run shows: The run ends with InputMismatchException, because the first thing the filling pass tries to read as a number is the word readings.
forgetting close() and finding an empty file
What a run shows: Nothing. Measured on the reference machine, every line of every check was identical with the close removed, because PrintStream(File) has no byte buffer of its own. A PrintWriter in the same shape does leave the file empty. The spec still asks for the close, and the checks do not see it.
passing a String to PrintStream
What a run shows: Nothing. The PrintStream(String) constructor opens the file, so the output is right. The leaf keeps this one because the same habit on the reading side is the pitfall above it, which does fail every check.
mode mismatch between Pass 1 and Pass 2
What a run shows: Nothing, with this file. Counting lines and reading whitespace-separated numbers agree when there is one number on each line, which is the shape the spec asks for. A file with two numbers on a line would separate them.
using while (sc.hasNext...) in Pass 2
What a run shows: Nothing, as long as the counting pass is right. An end-of-file loop fills the same slots. It stops being the same when the count is wrong, and then it hides the wrong count instead of showing it.

What this puts on your resume

You have written Java that creates a text file, reads it back in two separate passes to learn how many records it holds, and loads those records into an array sized to fit them.

What the program needs where it runs

The sandbox has to let the program create a file in the folder it runs in.
Each check runs in a folder of its own, or the file left by the previous check is read by the next one. The reference runs used a fresh temporary folder for every case.
Not yet confirmed on the deployed runner. This was verified locally only. No call was made to the Judge0 host from this pass.

Notes for the author, not part of the student page

This block is here so the manifest can be reviewed on the page instead of in the file. It is not rendered on a student page.

Why this is not ready to offer

Three of the six leaves this challenge certifies are not a subject leaf in any room of the path. A student who finishes the path has not been given them, so this challenge cannot be offered at the end of the path as it stands today.

printstream-over-a-file, needed for the half of the program that makes the file. The path has nothing. The path only reads files. No room writes one.
count-pass-returns-the-size, needed for the counting pass. The path has scanner-cannot-rewind-so-two-passes in the file-into-an-array room, which is why two passes are needed, and line-mode-end-of-file-loop, which is the loop shape. Neither is the counting method itself.
fill-pass-allocates-exactly-count, needed for the allocate-and-fill pass. The path has each-pass-opens-its-own-scanner in the file-into-an-array room, which is the discipline the two passes follow, not the fill method itself.

Two more rooms on the path, both after file-into-an-array. One that writes a PrintStream, and one that is the count-allocate-fill pattern end to end. Both already exist as spine leaves with stems, so both rooms are a manifest edit and no new curriculum.

Outcomes considered and left out

output-guaranteed-only-after-flush-or-close. Measured, not assumed. Removing close() from the writing method left every line of every check unchanged, so no run of this program demonstrates the guarantee. The observable is also written entirely in saying verbs, state, name and explain. Its neighbour printstream-over-a-file already carries the close clause, so certifying both would count one behavior twice.
scanner-cannot-rewind-so-two-passes. Its observable names two valid responses to the problem, the two-pass route and an ArrayList. A program that used an ArrayList would print the same output, so no stdout comparison can tell the two apart. Only a source scan can. The required headers ask for the two-pass shape, and the checks cannot see that they were honored.
each-pass-opens-its-own-scanner. A student who passes one Scanner into both passes fails the checks, but a student who constructs a fresh Scanner at the call site and passes it in prints exactly the right output while breaking the discipline. The checks cannot separate those two, so this is a source scan, not a run.
checked-versus-unchecked-classification. Out of scope on purpose. This challenge asks for the throws line and not the rule behind it, which is the named-depth bridge the path built in room 6 after a just-in-time ordering defect. Certifying the rule here would undo it.
handle-or-declare-rule. Same reason. The rule is room 8 material and it is stated, not run.
typed-token-reads-and-inputmismatch. The fill pass does use nextInt, but every value the program writes is one it read as an int, so no check can present a token that fails to parse. A check for this one needs a file the student did not write.

Why a run cannot see some clauses

printstream-over-a-file. Measured on the reference machine with probes V1NoClose and P6WriterNoClose. The runs and their numbers are in VERIFICATION.md. A PrintWriter in the same shape does leave the file empty, so the leaf's pitfall is right about PrintWriter and doubtful about PrintStream. That is a finding for whoever owns the leaf, and nothing in the spine was edited from here.
scanner-over-file-construct-and-close. The bank inventory reached the same conclusion in its own words, that a Judge0 stdout comparison cannot assert that a Scanner was closed. A source scan is the check kind that sees this one, and the spine already has source-scan checks on these leaves.

Scope decisions

file-not-found-exception-is-checked. This challenge asks for the line and not for the rule behind it. That is the named-depth bridge the path already uses in room 6, and it is why checked-versus-unchecked-classification is refused below.

Carried in from earlier rooms

file-object-holds-a-path-not-contents, from the room opening-a-file, at working depth
array-construction-with-new-and-size, from the room making-an-array, at working depth
array-bracket-access-read-and-write, from the room one-slot-at-a-time, at working depth
array-length-is-a-field, from the room one-slot-at-a-time, at working depth
counted-for-loop-over-array, from the room walking-every-slot, at working depth
accumulator-sum-and-average-cast, from the room computing-while-you-walk, at working depth

Assumed from earlier in the course

Reading numbers from standard input with a Scanner. Not a leaf in this seed unit, which covers arrays and file I/O only. The practice bank has it earlier in the course at lane-04-loops/07-accumulator-pattern/01-running-sum/exercises/sum-range-with-scanner.yaml, which reads an integer from standard input with a Scanner.

Where the expected output came from

solution: _reference/file-io-capstone/ReadingsFile.java
inputs: _reference/file-io-capstone/cases/
compiler: javac 25.0.1 (Temurin 25.0.1+8-LTS)
runtime: openjdk 25.0.1 2025-10-21 LTS (Temurin 25.0.1+8-LTS)
platform: macOS 26.5.2, arm64
captured: 2026-08-20 8:53 PM PDT, clock read with date
command: javac -d . ReadingsFile.java, then each case run in its own empty temporary folder so that a readings.txt left by an earlier case cannot be read by a later one: java -cp . ReadingsFile < cases/<id>.stdin
normalization: Java writes LF on this platform, so nothing was converted. VERIFICATION.md records the byte comparison and the CR count, which is zero.
run limits: 5 seconds of processor time and 131072 kilobytes, which are the practice bank values

Provenance

authored: 2026-08-20 8:45 PM PDT, clock read with date
spine_read: Leaf observables and pitfall headings read 2026-08-20 between 8:20 and 8:40 PM PDT from ~/Projects/jdoner-me-universe/spine/cscd210/07-file-io-and-exceptions/, whose MANIFEST.csv has an mtime of 2026-08-20 19:09.
path_read: Room membership read the same evening from ~/Projects/jdoner-me-universe/paths-prototype/paths/cscd210-arrays-fileio-catchup.yaml, mtime 2026-08-20 19:18.
agent: CC-MAC-JDONERME-0820, overnight wave, unit W4.

What this shows you can do

What to build

One worked example

Five readings, all positive

How your program is checked

One reading

Eight readings, mixed signs, with a repeated value

Three readings, all negative

What to watch for

What this puts on your resume

What the program needs where it runs

Mark it built

Notes for the author, not part of the student page

Why this is not ready to offer

Outcomes considered and left out

Why a run cannot see some clauses

Scope decisions

Carried in from earlier rooms

Assumed from earlier in the course

Where the expected output came from

Provenance