Homework 1: Unique Numbers

Homework is important practice for you, but it’s not graded so you don’t have to submit it. This particular homework is designed to help you review basic Java programming. There’s literally nothing new here.

Overview

You will develop a simple Java program Unique that analyzes the command line it is given in a peculiar way (see below). Please do not use any Java classes that serve as data structures, specifically not collection classes like ArrayList, HashMap, and friends. Plain old Java arrays are all you need.

The Program

The Unique program accepts any number of integers as command line arguments and prints each unique integer it was presented with to standard output. For example, the invocation

java Unique 0 0 1 0 1 0 0 0 10 1

might generate the output

0
1
10

whereas the invocation

java Unique 1 9 2 3 1 4 9 5 3 6 0

might generate the output

1
9
2
3
4
5
6
0

instead. Note that the order of numbers in the output doesn’t matter as long as you print the correct set of numbers, one line per number, without any additional output!

Errors

You may wonder what could possibly go wrong in Unique since it only looks at its arguments and then writes to standard output.

As defined above the program is supposed to work for integers only, not for arbitrary strings. In Java, command-line arguments are passed to the main method as strings however, so the program could be run as follows:

java Unique 0 0 1 woops 1 0 0.23 0 10 1

Obviously woops and 0.23 are not integers and therefore the program should not process them without complaining.

The “worst” way to handle this issue is to ignore it, because then you’re not implementing the correct program at all. (If you think you’ve found a way to do it, you may want to think again but more carefully.)

A “slightly better” way to handle the issue is to stop the program with an error message (printed to standard error, not standard output!) once an invalid argument is detected. This means that you might still print

0
1

to standard output before you stop with an error message for woops. The problem is that you’re essentially implementing a “garbage in, garbage out” strategy this way: because the input was incorrect, the output is incorrect as well. (That might sound “fair” in a way, but we can do better.)

A “better” way to handle the issue is to check whether all arguments are valid first, before the program produces any partial output. This means that for the above example you’d immediately stop with an error message. Now you’re at least not producing garbage output, but you’ve also forced the user to fix all the problems in the input before giving them any useful output.

The “best” way to handle the issue is to ignore strings that are not integers as far as determining uniqueness is concerned, but to also warn the user (with an error message to standard error) for each argument that was ignored. With this strategy the user gets all the information they could possibly want: The program tells them what all the unique integers were and it tells them all the arguments that it considers invalid.

Hints

Artifacts

At minimum, you should have a file Unique.java with your program in it. You should get no compiler warnings when compiling with -Xlint:all and no checkstyle warnings with the 601.226 configuration file posted on Piazza.

Ideally you’d also have a simple test framework (maybe based on shell scripts) but that’s not strictly-speaking course material; just something to look into if you feel like it. (You may have learned how to do this in 601.220 already.)