Problems are designed so that solutions can be written using concepts from the AP Java Subset. Other concepts may be useful and teams are welcome to employ them. Because of declining use, C++ is no longer supported.
Some problems involve writing static methods that, given an object and other parameters, query the object and produce some output or a return value. In such cases, we will provide the skeleton of the class in which the methods should be added.
Other problems involve adding methods to existing classes. When those methods are mutators (methods that change the state of the object they are invoked on), helper methods will be provided so that teams do not have to work directly with instance variables.
public class OozleTest
{
public static void main(String[] args)
{
System.out.println(Oozle.translate("this"));
}
}
then additional test cases could be added by adding the statements
System.out.println(Oozle.translate("is"));
System.out.println(Oozle.translate("confusing"));
System.out.println(Oozle.translate("eye"));
System.out.println(Oozle.translate("ornate"));
In cases where the arguments passed to a team-written method are objects or where teams are to add a non-static method to an existing class, methods will be provided so that teams can set up the objects as they wish before testing their method. For example, one problem required using a grid with colors such as
In this case there was a constructor to create an empty grid and a method to draw rectangles in the grid:
public class QuadTreeTest
{
public static void main(String[] args)
{
Grid d0 = new Grid(8); // makes an empty 8x8 grid
d0.storeValue(1, 0, 0, 3, 3); // draws red (color 1) at (0,0)-(3,3)
d0.storeValue(1, 0, 4); // draws red at (0,4)
d0.storeValue(2, 6, 7); // draws blue (color 2) at (6,7)
d0.storeValue(2, 7, 6); // draws blue at (7,6)
QuadTree t0 = new QuadTree(d0); // team-written constructor
System.out.println(t0);
}
}
In this case teams were expected to instantiate their own Grid objects and color them with the storeValue method: adding the code
Grid d1 = new Grid(4); d1.storeValue(1, 0, 0, 3, 1); d1.storeValue(2, 0, 2, 3, 3); QuadTree t1 = new QuadTree(d1); System.out.println(t1);would have tested the team-written QuadTree constructor on a 4x4 grid with the left half red and the right half blue.
In such cases there may also be a provided method to read test cases from files. See below of how such cases will be handled.
If input must be read from a file, there will be either a constructor that takes a filename as a parameter, a constructor that takes a Scanner object as a parameter, or a method in the supplied test driver that reads a file and creates an object. In all cases, opening the file and reading the input will be handled by supplied code and teams will not have to know how to use the java.io package or the Scanner class.
Once the data has been read into an object, teams can query the object via its methods to see what the input was. For example, in the grid example from above there was a method provided in the test driver to create a Grid object from data stored in the file. The Grid object was then passed to the team-written code, and that code could use the method int getSize() from the Grid class to return the size of the grid and a method int getValue(int x, int y) to return the color of a given position on the grid.
If teams create their own input files, they should carefully mimic the format in the provided input files. In particular, any special characters (for example, '.' to represent an empty space on a game board) should be used as in the provided input file, and whitespace characters should be used exactly as they were used in the provided input file (generally this means there should be a single space between values given on the same line, no blank lines, and no extra whitespace characters at the ends of lines). Do not count on the supplied input code to detect if the input file is malformed.
Output, when handled by team-written code,
will consist of System.out.print or
System.out.println statements. When sample output is given
in a problem description, it should be assumed, unless it is otherwise
stated, that there are no blank lines in the output, and that there are no
extra whitespace characters between the last non-whitespace character and
the newline character. For example, if the sample output is
Programming Contest 2008then acceptable code to produce that output would be
System.out.println("Programming Contest");
System.out.println("2008");
but not
System.out.println("Programming Contest "); // note the extra spaces
System.out.println("2008");
and not
System.out.println("Programming Contest");
System.out.println("2008");
System.out.println(); // there shouldn't be an extra blank line
No other System.out.println statements should be present in the submitted code. If such statements are used for debugging, they should be removed before the code is submitted.
Generic collection classes are now part of the AP Java subset. Therefore, where any provided code uses the Java Collections Framework, that code will use generics. We may, at our option, also provide alternate ways of using the collections without generics, for example if we provide a method List< Integer > getCodes() then there may also be a method List getCodesHeterogeneous(). Note that if such alternatives are present, then we will get the following compiler warnings
Note: StudentList.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details.which can be safely ignored for the purposes of the contest.
Furthermore, wherever collections are used, we will provide a way to access the items in the collection without using the collections classes. For example, we may provide methods to count the number of items in a collection, and retrieve the items by index, so that
List< String > l = students.getNames(); Iterator< String > i = l.iterator(); while (i.hasNext()) System.out.println(i.next());and
for (int i = 0; i < students.countNames(); i++) System.out.println(students.getName(i));would behave identically.