AP Computer Science A Quick Review

Java is statically typed --- every variable's type is fixed at declaration, and arithmetic between two int values always produces an int.

Core types int, double, boolean; declaration syntax int x = 5;; arithmetic operators + - * / %; integer division truncates toward zero, so 7 / 2 is 3, not 3.5; 7 % 2 is 1; compound assignment += -= *= /= %=; increment/decrement ++ and --.

/ between two ints (integer division, truncates) vs. / when at least one operand is a double (true decimal division) --- and = (assignment) vs. == (equality test).

Writing int avg = (a + b) / 2; when a and b are ints truncates the true average toward zero; you must cast first, e.g. (double)(a + b) / 2.

int / int $arrow$ int (truncates) $arrow$ cast to double to keep the decimal.

Casting explicitly converts a value between numeric types, and Java also promotes types automatically when an expression mixes an int with a double.

Explicit cast syntax (int) 7.9 yields 7 (truncates, never rounds); (double) 7 yields 7.0; mixing an int and a double in one expression auto-promotes the int to double before the operation; (int) always truncates toward zero --- to round a positive value, use (int)(x + 0.5).

Casting with (int) (truncates the decimal, no rounding) vs. Math.round() (actually rounds to the nearest integer).

Assuming (int) 4.999 rounds up to 5 --- it truncates down to 4.

(int) always chops the decimal, never rounds.

An object is an instance of a class, created with new, and manipulated only through its constructors and public methods (dot notation).

Instantiation: ClassName obj = new ClassName(args);; calling a method: obj.methodName(args);; a class's public interface = its constructors plus its public methods; void methods return nothing, non-void methods return a value that must be stored, printed, or used.

A class (the blueprint/template, written once) vs. an object (a specific instance built from that blueprint, created every time new runs) --- String is a class; "hello" is an object of that class.

Assuming that calling a method automatically updates the variable you called it on --- unless the method mutates the object's own instance variables, or you explicitly reassign the variable with the method's return value, nothing changes.

new ClassName(...) builds it; dot notation uses it.

Primitive variables store the actual value; object variables store a reference (an address) to the object, so two variables can point at the very same object.

Assigning one object variable to another (b = a;) copies the reference, not the object --- both variables now point to the same object; Java is always pass-by-value, and for an object that "value" is the reference itself, so a method can mutate the object's fields but reassigning the parameter inside the method never affects the caller's variable; an uninitialized object reference equals null; calling a method on a null reference throws a NullPointerException.

Java's actual pass-by-value semantics for object references vs. the common misconception that Java objects are "passed by reference."

Calling .equals() or any method on a variable that might be null (e.g. the result of a search that found nothing) throws a NullPointerException at runtime --- always test if (result != null) first.

Object variable = an address, not the object; null.anything() $arrow$ crash.

String objects are immutable --- every String method returns a brand-new String rather than modifying the original --- and String content must be compared with .equals(), never ==.

str.length(); str.substring(a, b) returns characters from index a up to (not including) index b; str.substring(a) returns from a to the end; str.indexOf(target) returns the first index of target or -1 if absent; str.charAt(i); str.equals(other) for content equality; str.compareTo(other) returns negative/zero/positive for alphabetical order.

== (compares whether two references point to the same object) vs. .equals() (compares actual character content) --- two different String objects holding identical text are .equals() but may not be ==.

Using if (s1 == s2) to compare String content can appear to "work" for string literals but silently fails and returns false for Strings built with new String(...), substring(), or concatenation, even when the text matches exactly.

Strings: compare content with .equals(); never ==.

Wrapper classes let a primitive value be treated as an object (required for generic collections like ArrayList), and Java auto-converts between the two via autoboxing/unboxing.

Integer.parseInt(String) and Double.parseDouble(String) convert text to numbers; Integer.MIN\_VALUE / Integer.MAX\_VALUE; autoboxing lets Integer x = 5; wrap an int automatically, and unboxing happens automatically in arithmetic; Math.abs(x), Math.pow(base, exp), Math.sqrt(x), Math.max(a,b), Math.min(a,b), and Math.random() which returns a double in $[0, 1)$.

ArrayList<int> (illegal --- generics require an object type) vs. ArrayList<Integer> (legal, uses the wrapper class).

Math.random() never returns exactly 1.0 and can return 0.0, so (int)(Math.random() * n) produces integers from 0 to n-1 inclusive --- exam questions often ask you to correctly shift/scale this range.

Math.random() $arrow$ [0,1); scale by *n, shift by +min.

A boolean expression always evaluates to exactly true or false, and compound expressions combine them with &&, ||, and !.

Relational operators < > <= >= == !=; logical AND &&, logical OR ||, logical NOT !; && and || use short-circuit evaluation --- in a && b, if a is false, b is never evaluated; in a || b, if a is true, b is never evaluated.

Bitwise & and | (always evaluate both sides) vs. logical && and || (short-circuit) --- the AP CSA exam tests && and ||.

Reversing the order of a short-circuited safety check --- e.g. writing arr[i] == 0 && i < arr.length instead of i < arr.length && arr[i] == 0 --- lets the array access run before the bounds check and can throw an ArrayIndexOutOfBoundsException.

&& stops at first false; || stops at first true.

Only one branch of an if/else if/else chain ever executes, and conditions are tested top to bottom until one is true.

Syntax pattern: if (condition) \ ... \ else if (condition2) \ ... \ else \ ... \; each else binds to the nearest unmatched if; once one branch's condition is true, all later branches are skipped even if they would also evaluate true.

A sequence of separate, independent if statements (every condition is checked, multiple blocks can run) vs. an if/else if/else chain (only one block ever runs).

Writing consecutive independent if statements instead of else if lets multiple blocks execute when only one was intended --- e.g. a letter-grade method with separate ifs can fall through and overwrite the result more than once.

else if chain $arrow$ first true branch wins, rest are skipped.

Any compound boolean expression can be rewritten into an equivalent form with De Morgan's Laws --- a frequent MCQ "equivalent expression" question.

$(a b) ( a) ( b)$; $(a b) ( a) ( b)$; negating a relational operator flips it: $(x < y) (x ≥q y)$ and $(x = y) (x ≠ y)$.

The incorrect negation !a && !b for !(a && b) vs. the correct De Morgan negation !a || !b.

On "which expression is equivalent" MCQs, negating only one side of a compound expression, or forgetting to flip && to || (or vice versa) while distributing the !.

!(A && B) = !A || !B; !(A || B) = !A && !B.

A while loop checks its condition before every pass and repeats as long as that condition is true --- possibly zero times.

Syntax while (condition) \ ... \; the body must eventually change something that affects the condition, or the loop never terminates; a while loop can run zero times if its condition is false from the start.

while (condition checked before each pass, may run zero times) vs. a for loop with a counter (also condition-first, but bundles the init/condition/update together in one header).

Forgetting to update the loop-control variable inside the body creates an infinite loop; tracing a while loop and stopping one iteration too early or too late is one of the most common point losses on the exam.

while checks first $arrow$ can run zero times $arrow$ must update inside the body.

A for loop packages initialization, the continuation test, and the update into one header, and the classic AP CSA bug is getting the boundary condition wrong by exactly one.

Syntax for (int i = 0; i < n; i++) \ ... \; to traverse a collection of size n, valid indices run 0 through n-1, so the standard header uses i < n, never i <= n.

i < arr.length (correct --- stops right after the last valid index) vs. i <= arr.length (wrong --- throws ArrayIndexOutOfBoundsException on the final pass).

Using <= instead of < in a loop bound is an off-by-one error --- it either skips the last element (if the bound is too small) or throws an exception by running one iteration too many (if the bound is too large).

n items $arrow$ valid indices 0..n-1 $arrow$ always use i < n.

In nested loops, the inner loop runs to full completion for every single pass of the outer loop, so total iterations multiply.

When both loops are independent counters, total iterations = (outer count) $×$ (inner count); this pattern drives 2D array traversal and pattern printing; the inner loop's variable typically resets each time the outer loop advances.

Independent nested loops, for (i...) for (j...) with total iterations = rows $×$ cols, vs. a loop whose inner bound depends on the outer variable (e.g. for (int j = 0; j < i; j++)), which produces a triangular pattern with fewer total iterations.

Miscounting total iterations when tracing a nested loop and predicting output length, especially when the inner loop's bound is a function of the current outer-loop variable.

outer $×$ inner = total passes, unless inner bound depends on outer.

Most exam loop-writing questions are variations on three canonical patterns: accumulate a running total, count matches, or track a running maximum or minimum.

Accumulator: initialize int sum = 0; before the loop, then sum += value; inside it; counter: int count = 0; before the loop, then if (condition) count++; inside it; max: seed int max = arr[0]; then loop from index 1, updating if (arr[i] > max) max = arr[i];.

Seeding a max/min accumulator to 0 (fails whenever every array value is negative) vs. seeding it to arr[0] (always correct) --- a very common AP CSA scoring point.

Declaring the accumulator or counter variable inside the loop body resets it to its initial value on every pass, so it never actually accumulates anything.

sum/count/max: init BEFORE the loop; seed max/min with arr[0], not 0.

A class bundles instance variables (its data) with methods (its behavior), and a constructor's only job is to initialize a new object's instance variables.

A constructor shares the class's exact name and has no return type, not even void --- e.g. instance variables private String name; private int age; paired with the constructor public Dog(String n, int a) \ name = n; age = a; \; uninitialized instance variables get automatic default values: numeric types default to 0, boolean to false, object references to null; a class can overload multiple constructors with different parameter lists.

A constructor (no return type, same name as the class, runs once automatically with new) vs. a regular method (has a return type, can be called any number of times).

Writing void Dog(...) turns the intended constructor into a plain (buggy) method that must be called explicitly and never runs automatically when new Dog(...) executes.

Constructor = class's name, no return type, runs on new.

Because instance variables are typically private, a class exposes controlled access to them through public accessor (getter) and mutator (setter) methods.

Accessor pattern: public int getAge() \ return age; \; mutator pattern: public void setAge(int a) \ age = a; \; accessors return a value and take no state-changing parameters; mutators return void and take the new value as a parameter; Class-design FRQs are graded on exactly matching each required method's name, parameter types, and return type.

Accessor methods (return a value, leave state unchanged) vs. mutator methods (change instance-variable state, typically return void).

On the Class Creation FRQ, losing points for a getter that takes a parameter, a setter that returns a value, or a method signature that doesn't exactly match what the prompt specifies.

get = return value, no side effect; set = void, changes state.

this refers to the current object, and Java distinguishes overloaded methods purely by their parameter list, never by return type alone.

this.name = name; disambiguates an instance variable from a same-named parameter; this(...) can call another constructor in the same class; method overloading means multiple methods share a name but differ in the number or types of parameters within the same class.

Method overloading (same name, different parameter lists, resolved by the compiler, all within one class) vs. method overriding (a subclass redefines an identical signature --- vocabulary students still mix up even though inheritance is no longer in the current AP CSA framework).

Assuming two methods can share a name and identical parameters but differ only in return type --- Java does not allow overloading by return type alone, and this is a compile error.

this.field vs. same-named parameter; overload = same name, different parameters.

An instance member belongs to (and varies per) each individual object, while a static member belongs to the class itself and is shared by every instance.

Static variable: private static int count; --- one shared copy across every object of the class; static method: public static int getCount() \ return count; \, called as ClassName.methodName() rather than on an instance; a static method has no this and cannot directly access instance (non-static) variables or call instance methods.

Instance variables (each object gets its own separate copy) vs. static/class variables (one shared copy for the entire class, commonly used to count how many objects have been created).

Referencing an instance variable directly inside a static method causes a compile error; forgetting to access static members through the class name (ClassName.field) is a common syntax slip on the exam.

static $arrow$ one shared copy, ClassName.member; instance $arrow$ one per object.

Access modifiers control visibility, variable scope controls lifetime, and documentation --- while not separately scored --- shows up throughout FRQ prompts.

private --- accessible only within the declaring class, the AP CSA standard for instance variables; public --- accessible from any class, the standard for constructors and most methods; a variable declared inside a method or loop exists only within that block (local scope); comment syntax // for a single line, /* ... */ for multiple lines, and /** ... */ for Javadoc-style documentation.

A local variable declared inside a method (dies the instant the method returns) vs. an instance variable declared in the class body outside any method (persists for the entire life of the object).

Declaring a variable inside an if block or loop and then trying to use it after the block ends causes a "cannot find symbol" compile error --- its scope ended at the closing brace.

private data, public behavior; scope ends at the closing brace.

An array is a fixed-size, ordered collection of same-typed elements, indexed from 0 to length - 1.

Declaration int[] arr = new int[5]; (5 elements, default value 0) or int[] arr = \2, 4, 6, 8, 10\; (an initializer list sets both size and values); access/assign with arr[i]; size is arr.length --- no parentheses; once created, an array's size is fixed and can never grow or shrink.

arr.length (array size, a field, no parentheses) vs. str.length() (String size, a method, with parentheses) vs. list.size() (ArrayList size, a method, with parentheses).

Writing arr.length() or list.length --- mixing up which collection type uses a field vs. a method for its size is one of the most common syntax errors on the FRQ section.

array.length (no parens); String.length() and List.size() (parens).

Nearly every array FRQ is a single traversal loop combined with an accumulator, a comparison, or a counter inside it.

Linear search: for (int i = 0; i < arr.length; i++) \ if (arr[i] == target) return i; \ return -1;; sum/average: accumulate with sum += arr[i]; inside the loop, then cast before dividing: double avg = (double) sum / arr.length;.

Searching an unsorted array (must check every element, linear search only) vs. a sorted array (binary search becomes available and is far faster).

Computing an average with sum / arr.length when both are int truncates the decimal portion --- you must cast to double before the division, not after.

Sum first, cast before you divide.

The enhanced for loop simplifies read-only traversal of an entire array or ArrayList, but it hands you a copy of each value, not an index.

Syntax for (int val : arr) \ ... \ or for (String s : list) \ ... \; visits every element in order from first to last; val = 5; inside the loop does not change arr --- it only reassigns the local copy; cannot be used when the index itself is needed.

The enhanced for-each loop (no index available, read-only copy of each element) vs. a standard indexed for loop (gives you i, needed to modify elements, traverse backward, or compare adjacent elements).

Removing elements from an ArrayList while iterating it with a for-each loop throws a ConcurrentModificationException --- use a backward indexed loop instead.

for-each $arrow$ read-only copies, no index; need to modify/index $arrow$ use a regular for.

ArrayList is a resizable, generic collection --- unlike an array it can grow or shrink, but it can only hold object types.

Declaration ArrayList<Integer> list = new ArrayList<>(); (diamond operator); key methods list.size(), list.add(obj) (appends), list.add(i, obj) (inserts at index i), list.get(i), list.set(i, obj) (replaces, returns the old value), list.remove(i) (removes by index, returns the removed value).

list.remove(2) on an ArrayList<Integer> removes the element at index 2, not the value 2, because an int argument matches the index-based overload; to remove the value 2 you must pass Integer.valueOf(2) or (Integer) 2 to trigger the remove-by-object overload.

Calling add/get/set/remove with an out-of-range index throws IndexOutOfBoundsException; assuming remove(int) removes by value instead of by index is a classic exam trap.

ArrayList: add/get/set/remove by index; size() has parens.

Removing or inserting elements while traversing an ArrayList forward shifts every later index down, silently skipping elements --- so removal loops must run backward.

Safe removal pattern: for (int i = list.size() - 1; i >= 0; i--) \ if (condition) list.remove(i); \; going backward means already-processed indices below i are never disturbed by the shift; forward traversal for (int i = 0; i < list.size(); i++) is fine when you are only reading, not removing.

Forward removal (i increases while remove shifts everything left, skipping the element that shifts into the just-vacated spot) vs. backward removal (safe, because indices below i never move).

Removing elements in a forward loop while incrementing i every pass silently skips the element right after every removal, producing a wrong result without ever throwing an exception --- one of the hardest AP CSA bugs to spot by inspection.

Removing? Go backward: i = size()-1 down to 0.

A 2D array in Java is really an array of arrays, though AP CSA problems almost always use uniform rectangular grids.

Declaration int[][] grid = new int[3][4]; (3 rows, 4 columns, all zeros) or int[][] grid = \\1,2\,\3,4\,\5,6\\;; access/assign with grid[row][col]; number of rows = grid.length; number of columns in a given row = grid[0].length (or grid[row].length in general).

grid.length (number of rows) vs. grid[0].length (number of columns in row 0) --- mixing these two up is the single most common 2D-array syntax error.

Swapping row and column indices, grid[col][row] instead of grid[row][col], compiles fine but silently accesses or updates the wrong cell (or throws an out-of-bounds exception if the grid isn't square).

grid.length = rows; grid[0].length = columns; access grid[row][col].

A 2D array is visited with nested loops, and swapping which loop is outer changes the traversal order without changing the underlying data.

Row-major, the standard AP CSA pattern: for (int r = 0; r < grid.length; r++) \ for (int c = 0; c < grid[r].length; c++) \ /* process grid[r][c] */ \ \; column-major swaps which loop is outer so an entire column is processed before moving to the next column.

Row-major traversal (processes an entire row before moving to the next row) vs. column-major traversal (processes an entire column before moving to the next column) --- the same nested-loop skeleton produces a different visiting order depending on which index is outer.

Using grid.length as the inner loop's bound instead of grid[r].length silently uses the wrong number of columns whenever a grid is not perfectly square.

outer r, inner c $arrow$ row-major; outer c, inner r $arrow$ column-major.

Linear search checks elements one at a time and works on any array; binary search is far faster but only works correctly on data that is already sorted.

Linear search: $O(n)$ worst case, works sorted or unsorted; binary search: $O( n)$ worst case, repeatedly compares the target to the middle element and discards half the remaining range each step, and requires the array to be sorted first; both commonly return the target's index, or -1 if the search range is exhausted without a match.

Linear search (no precondition, $O(n)$) vs. binary search (must be sorted first, $O( n)$) --- running binary search on unsorted data compiles fine but can silently return the wrong result.

Assuming binary search works on any array; the exam often provides an unsorted array specifically to test whether students recognize binary search cannot be applied directly.

Sorted? Binary search, $O( n)$. Unsorted? Linear only, $O(n)$.

Selection sort and insertion sort are both $O(n^2)$ nested-loop algorithms, but they build the sorted portion of the array in different ways.

Selection sort repeatedly finds the minimum of the unsorted remainder and swaps it into place at the front, for each position from the first index to the second-to-last; insertion sort repeatedly takes the next element and shifts it backward into its correct position among the already-sorted elements before it, like sorting a hand of playing cards; both run in $O(n^2)$ time in the worst case.

Selection sort (searches the unsorted part for the next minimum, then swaps it to the front) vs. insertion sort (shifts the sorted part to make room, then inserts the next element in place).

On a trace question, mixing up which portion of the array is already "settled" --- selection sort finalizes the front portion in place, but insertion sort's already-placed elements can still shift right as later elements are inserted.

Selection: find min in unsorted, swap to front. Insertion: shift sorted part, drop element in.

The Scanner class reads tokens --- numbers, words, or whole lines --- sequentially from a source such as a file, and every read call advances a cursor forward through that input.

Typical file-reading pattern: File f = new File("data.txt"); Scanner input = new Scanner(f); while (input.hasNext()) \ int n = input.nextInt(); \ input.close();; input.nextInt(), input.nextDouble(), input.next() (one whitespace-delimited token), input.nextLine() (the rest of the current line); input.hasNext() / input.hasNextInt() check whether input remains before you read it.

next() (reads a single token up to whitespace) vs. nextLine() (reads everything up to and including the newline) --- calling nextLine() right after nextInt()/nextDouble() only consumes the leftover newline character, not a new line of data.

Mixing nextInt() and nextLine() without an extra "flush" call to nextLine() in between causes the very next nextLine() to return an empty string instead of the intended data, because it consumes the leftover newline first.

hasNext() before next(); nextInt() leaves a newline -- flush it with an extra nextLine().

Real-world data processing on the exam combines the same core patterns you already know --- accumulate, filter, and transform --- applied one after another to a collection of records.

Filtering pattern: build a new ArrayList and only add elements that satisfy a condition, rather than removing from the original while iterating; it is common to filter a data set with one loop, then compute a statistic (sum, average, count) on the filtered result with a second loop; when data comes from parallel arrays or a list of records, the same loop index reads corresponding fields together.

Filtering by building a new collection that holds only the qualifying elements (safe, simple) vs. filtering by removing non-qualifying elements from the original list while traversing it forward (needs the backward-removal pattern, or it skips elements).

Trying to filter, accumulate, and remove from the same list in a single forward pass combines two loop patterns incorrectly and is a common source of subtle logic bugs on data-set FRQs.

Build a new filtered list; don't remove while looping forward.

The current AP CSA exam only requires you to trace a given recursive method and predict its output or return value --- you are not required to write a recursive method yourself.

Every correct recursive method needs a base case (stops the recursion without another call) and a recursive case (calls itself with an argument that moves closer to the base case); trace by treating each call as its own frame with its own copy of parameters and local variables; a call cannot finish until the recursive call it made returns first, so trace inward to the base case, then unwind outward; classic traced example: factorial, where f(n) returns 1 if n == 0, otherwise returns n * f(n - 1).

Tracing recursion (follow the call stack down to the base case, then combine return values back up in reverse order) vs. tracing an iterative loop (state updates in one flat pass, nothing "returns up").

Forgetting that the last recursive call to return is the first one made after the base case --- students often combine return values in call order instead of the correct reverse (unwind) order.

Recurse down to the base case, then combine answers back up in reverse order.

Length has no parens on arrays; every collection method call does.

When two terms feel interchangeable on this exam, they almost never are.

Know which class owns which method before you try to call it.

The reference sheet covers String/Integer/Double/Math/ArrayList/Object basics only --- Scanner and parseInt must be memorized.

Signature first, loop bounds second, hand-trace last.

42 MCQ + 4 FRQ, 3 hours total, 55/45 split, all on Bluebook.

Trace one statement at a time; never skip ahead to guess the answer.

Compiles but crashes? Suspect null, an index, or a division by zero first.

If a rule sounds too convenient, it's probably the trap.