Mock Exam #1: Brutal Trap Gauntlet

This is a classic trap involving integer division. When you divide two integers in Java, the result is also an integer, with any fractional part discarded. So, x / y (which is 5 / 2) evaluates to 2, not 2.5. Only after this calculation is the integer 2 promoted to a double (2.0) to be stored in the variable z. So, 2.0 is what gets printed. To get 2.5, you would need to cast one of the operands to a double first, like (double) x / y.

Here's a core concept you must remember: String objects in Java are immutable. This means they cannot be changed once they are created. The substring method doesn't modify the original string; instead, it creates and returns a new string. In this code, the new string "Hello" that is returned by greeting.substring(0, 5) is never stored in a variable. The original greeting variable still points to the unchanged string "Hello, world!". Therefore, that's what gets printed.

This question tests your understanding of short-circuit evaluation with the logical AND (&&) operator. Java evaluates boolean expressions from left to right. With &&, if the first condition is false, the entire expression must be false, so Java doesn't bother evaluating the second condition. Here, isPositive(-5) is called first. It increments checks to 1 and returns false. Because the first part is false, the && short-circuits, and isPositive(10) is never called. Therefore, checks is only incremented once.

This is a very common mistake when working with 2D arrays. The inner loop's condition is j < grid[0].length, which means it always assumes that every row has the same number of columns as the first row (row 0). This works for rectangular arrays. However, if you have a 'ragged' array where a subsequent row is shorter than the first row, the inner loop will try to access an index that doesn't exist for that shorter row, throwing an ArrayIndexOutOfBoundsException. For example, if row 0 has 5 elements and row 1 has only 3, when i is 1, the inner loop will try to access grid[1][3], which is out of bounds.

This is a subtle but critical error called 'shadowing'. Inside the constructor public Gadget(int id), the parameter name id is the same as the instance variable name id. When you write id = id;, you are referring only to the parameter—you're assigning the parameter's value to itself. The instance variable id is never touched. Since instance variables of type int are given a default value of 0 if not explicitly initialized, the id field of the myGadget object remains 0. To fix this, you must use the this keyword to distinguish the instance variable: this.id = id;.

Let's trace the values of i for which the loop condition i <= 5 is true. The loop will execute for i = 0, i = 1, i = 2, i = 3, i = 4, and i = 5. When i becomes 6, the condition 6 <= 5 is false, and the loop terminates. If you count them up, that is a total of 6 iterations. This is a common place to make an off-by-one error. Always be careful with < versus <= in your loop conditions!

This question tests your knowledge of the overloaded remove method in ArrayList. When you pass an int to remove, like scores.remove(2), you are calling the remove(int index) version of the method. This removes the element at the specified index. In the list [90, 85, 100, 75], the element at index 2 is 100. After it's removed, the list becomes [90, 85, 75]. The common mistake is to think it removes the Integer object with the value 2, but there is no 2 in the list. To remove by value, you would need to use scores.remove(Integer.valueOf(100)).

Let's break this down. Math.random() gives you a double value in the range [0.0, 1.0), meaning it includes 0.0 but not 1.0.

1. Math.random() * 6 produces a double in the range [0.0, 6.0).
2. Casting to an int with (int) truncates (chops off) the decimal part. So, (int)(Math.random() * 6) gives you an integer from the set {0, 1, 2, 3, 4, 5}.
3. Since we want a die roll from 1 to 6, we need to add 1 to this result. This shifts the range to {1, 2, 3, 4, 5, 6}. Therefore, (int) (Math.random() * 6) + 1 is the correct expression. Choice D is incorrect due to order of operations; it would cast Math.random() to 0 before multiplying.

This question highlights a key behavior of the enhanced for loop (or for-each loop) with primitive data types like int. The loop variable, val, holds a copy of each element from the array, not a reference to the element itself. When the line val = val * 2; is executed, you are only changing the value of the temporary copy val. The original values in the nums array are unaffected. Therefore, after the loop finishes, nums still contains {10, 20, 30}.

This problem requires you to carefully trace the execution of nested loops. Let's go step-by-step:

• Outer loop starts: i = 0. word.length() is 2.
  • Inner loop j = 0: i == j is true. result becomes "A".
  • Inner loop j = 1: i == j is false. result becomes "A-".
• Outer loop continues: i = 1.
  • Inner loop j = 0: i == j is false. result becomes "A--".
  • Inner loop j = 1: i == j is true. result becomes "A--P". The loops finish, and the final value of result is "A--P". Tracing problems like this are all about patience and keeping track of your variables one step at a time.

This is a tricky but fundamental concept in Java: pass-by-value. When you pass an object like maya to a method, you are passing a copy of the reference (the object's memory address).

1. Inside changeStudent, the local variable s initially points to the same Student object as maya.
2. s.setName("Priya") follows this reference and successfully changes the name of the original object to "Priya".
3. s = new Student("Carlos") is the key part. This line does NOT change the original maya object. It only changes the local variable s to point to a brand new Student object. The maya variable in runTest is completely unaffected by this reassignment.
4. s.setName("Jordan") then changes the name of this new, second object, which is then discarded when the method ends. So, the original object that maya refers to had its name changed to "Priya" and that's it.

Remember that arrays in Java are zero-indexed, which means the first element is at index 0. So, in the days array:

• days[0] is "Mon"
• days[1] is "Tue"
• days[2] is "Wed"
• days[3] is "Thu"
• days[4] is "Fri" The statement asks for the element at index 3, which is "Thu".

De Morgan's laws are essential for simplifying boolean expressions. The law for an AND expression states that !(A && B) is equivalent to !A || !B. Let's apply that here:

• A is x > 5. The negation, !A, is x <= 5.
• B is y < 10. The negation, !B, is y >= 10.
• The && becomes an ||. Putting it all together, !(x > 5 && y < 10) becomes x <= 5 || y >= 10. Be very careful with the negations: the opposite of > is <=, and the opposite of < is >=.

A linear search works by checking each element sequentially, starting from the beginning. The best case is finding the element at the first position (1 comparison). The number of comparisons increases as the element's position gets further down the array. The absolute worst-case scenario occurs when the algorithm has to check every single element. This happens in two cases: 1) the target element is the very last one in the array, or 2) the target element isn't in the array, forcing the search to go through all n elements before concluding it's not there. Both of these situations require the maximum number of comparisons.

This question tests the critical difference between == (reference equality) and .equals() (content equality) for objects.

• s1.equals(s3) is true because .equals() checks if the character sequences are the same, which they are.
• s1 == s2 is true. Because s1 and s2 are both string literals with the same value, the Java compiler optimizes by placing them in a 'string pool', making both variables point to the exact same object in memory.
• s1 == s4 is true because s4 is explicitly assigned the reference of s1. They point to the same object.
• s1 == s3 is false. The new keyword forces the creation of a new, separate String object in memory, even if its content is identical to an existing one. Since s1 and s3 point to different objects in memory, the == operator, which checks if the references are the same, returns false.

This is a direct test of access modifiers. The speed instance variable in the Car class is declared as private. This means it can only be accessed from within the Car class itself. The Traffic class is an external class, so it does not have permission to directly access or modify myCar.speed. This is a violation of encapsulation rules, and the Java compiler will catch it, resulting in a compile-time error. To allow external classes to modify the speed, the Car class would need to provide a public method, like public void setSpeed(int newSpeed).

Let's trace the loop carefully. The variable k is only incremented inside the if statement, which only runs when k is even.

• Iteration 1: k is 0. k < 10 is true. k % 2 == 0 is true. k becomes 1. count becomes 1.
• Iteration 2: k is 1. k < 10 is true. k % 2 == 0 is false. The if block is skipped. k remains 1. count becomes 2.
• Iteration 3: k is 1. k < 10 is true. k % 2 == 0 is false. The if block is skipped. k remains 1. count becomes 3. At this point, k is stuck at 1. It will never become even again, so it will never be incremented. The while (k < 10) condition will therefore always be true, leading to an infinite loop.

This is a classic and tricky problem that happens when you remove elements from an ArrayList while iterating forward. When you remove an element, the size of the list shrinks, and all subsequent elements shift to the left.

1. i = 0: names.get(0) is "Aaliyah" (length 7). The if is false.
2. i = 1: names.get(1) is "Ben" (length 3). The if is true. names.remove(1) is called. The list is now ["Aaliyah", "Carlos", "Priya"]. "Carlos" has shifted from index 2 to index 1.
3. Loop continues: i increments to 2. The loop condition i < names.size() (2 < 3) is true. The loop now checks names.get(2), which is "Priya". The element "Carlos", which is now at index 1, was skipped entirely!
4. i = 2: names.get(2) is "Priya" (length 5). The if is false.
5. Loop ends. The final list is ["Aaliyah", "Carlos", "Priya"].

This recursive method is designed to sum the digits of an integer. Let's trace the calls:

1. mystery(345) is called. Since 345 is not less than 10, it returns mystery(345 / 10) + (345 % 10). This simplifies to mystery(34) + 5.
2. Now we must solve mystery(34). Since 34 is not less than 10, it returns mystery(34 / 10) + (34 % 10). This simplifies to mystery(3) + 4.
3. Now we must solve mystery(3). Since 3 is less than 10, the base case is met, and the method returns 3.
4. Now we can substitute back. The call from step 2, mystery(3) + 4, becomes 3 + 4, which is 7.
5. Finally, we substitute this into step 1. The call mystery(34) + 5 becomes 7 + 5, which is 12. The final result is 12.

This question tests the 'dangling else' rule. An else statement always pairs with the nearest preceding if that doesn't already have an else. Let's trace the logic:

1. score is 85.
2. The first condition, score >= 90, is false.
3. The code moves to the else if (score >= 80). This condition is true.
4. Now we enter the code associated with that else if. It's a nested if: if (score >= 88). This condition is false (85 is not >= 88).
5. Because the nested if is false, its corresponding else block is executed. The else sets grade = "B+". The common mistake is to think this else belongs to the very first if, but it belongs to the closest one, if (score >= 88).

Let's trace this together! The method getPlayerTotal is asked to find the total for playerIndex 1. This means we're summing up all the scores in column 1.

The scores grid is: { {15, 22, 18}, // row 0 {20, 25, 21}, // row 1 {12, 16, 30}, // row 2 {28, 24, 26} } // row 3

The loop iterates through the rows (r from 0 to 3) and adds the element at scores[r][1] each time.

• When r is 0, it adds scores[0][1], which is 22.
• When r is 1, it adds scores[1][1], which is 25. (Total is 22 + 25 = 47)
• When r is 2, it adds scores[2][1], which is 16. (Total is 47 + 16 = 63)
• When r is 3, it adds scores[3][1], which is 24. (Total is 63 + 24 = 87)

The final total is 87. This is why B is correct.

Choice A is tempting; it's the sum of row 1 (20 + 25 + 21 = 66, actually, so not even that). Choice C is the sum of column 2 (18+21+30+26=95). A common mistake is to mix up rows and columns. Remember, the first index is the row, and the second is the column: [row][col]. Choice D is incorrect because the loop bounds (r < scores.length, which is 4) and the column index (1) are both valid for this grid.

This is a great problem for practicing tracing nested loops. Let's walk through the outer loop step by step.

• outer is 5: The inner loop runs for inner = 0, 1, 2, 3, 4. That's 5 times. count becomes 5.
• outer is 3: The outer loop updates by outer -= 2, so it's now 3. The inner loop runs for inner = 0, 1, 2. That's 3 times. count becomes 5 + 3 = 8.
• outer is 1: The outer loop updates by outer -= 2 again, so it's now 1. The inner loop runs for inner = 0. That's 1 time. count becomes 8 + 1 = 9.

After this, outer becomes -1. The condition outer > 0 is now false, and the loop terminates. The final value of count is 9.

Choice D (15) is what you'd get if the outer loop was outer-- (5+4+3+2+1). Choice B (8) is a common mistake where you might forget the final iteration of the outer loop when outer is 1. Choice A (5) is what you'd get if you only traced the first iteration of the outer loop.

Recursive string problems can feel like a puzzle. The key is to trace the calls one by one until you hit the base case, and then build the answer back up.

The base case is s.length() <= 1. The recursive step takes the last character, adds the result of mystery on the inner part of the string, and then adds the first character.

1. mystery("APPLE") calls mystery("PPL"). It will return: 'E' + mystery("PPL") + 'A'.
2. mystery("PPL") calls mystery("P"). It will return: 'L' + mystery("P") + 'P'.
3. mystery("P") hits the base case (length is 1) and returns "P".

Now, let's substitute back up:

• The call from step 2 gets "P" back, so it returns 'L' + "P" + 'P', which is "LPP".
• The call from step 1 gets "LPP" back, so it returns 'E' + "LPP" + 'A', which is "ELPPA".

This is why A is the correct answer. The other choices come from small mistakes in the recursive logic. Choice B might come from mixing up the order of concatenation. Choice C might come from putting the charAt(0) first. Choice D could happen if you made an off-by-one error in the substring call, for example using s.length() - 2 and losing a character.

This question tests your understanding of some key String methods. Let's break it down.

1. String event = "AP-CSA-EXAM"; Our string is "AP-CSA-EXAM".
2. int dash1 = event.indexOf("-"); This finds the index of the first occurrence of "-". The first dash is at index 2. So, dash1 is 2.
3. int dash2 = event.indexOf("-", dash1 + 1); This finds the index of the next occurrence of "-", but it starts searching from index dash1 + 1 (which is index 3). The next dash is at index 6. So, dash2 is 6.
4. String result = event.substring(dash1 + 1, dash2); This is the crucial step. We're taking a substring from index 2 + 1 (which is 3) up to (but not including) index 6.

The characters at indices 3, 4, and 5 are 'C', 'S', and 'A'. So, the substring is "CSA".

This is where many students slip up: remembering that the second parameter of substring is the endIndex and it's exclusive. The character at the endIndex is not included in the result. Choice D is a common error if you misunderstand how substring's parameters work.

This is a classic trap involving the this keyword! Look closely at the constructor:

public Student(String name, int id) { name = name; this.id = id; }

In the line name = name;, both names refer to the parameter name. The parameter is being assigned to itself, which does nothing. The instance variable private String name; is never assigned a value. This is called "shadowing"—the parameter name hides the instance variable name.

To fix this, the line should have been this.name = name;. The this keyword is used to specify that we mean the instance variable that belongs to this object.

Since the instance variable name was never initialized, it retains its default value, which for an object type like String is null. Therefore, s1.getName() returns null.

This is one of the most common and tricky ArrayList traps on the AP exam. When you remove an element from an ArrayList using an index, all subsequent elements shift to the left. If you are iterating forward with an index-based loop, this can cause you to skip the very next element.

Let's trace it carefully:

• Initial values: [2, 4, 5, 6, 7]
• i = 0: values.get(0) is 2 (even). values.remove(0) is called. The list becomes [4, 5, 6, 7]. The loop finishes, and i increments to 1.
• i = 1: Here's the trap! The list has shifted. values.get(1) is now 5, not 4. The 4 was skipped because it moved into the index i just passed over. 5 is not even, so nothing happens. i increments to 2.
• i = 2: values.get(2) is 6 (even). values.remove(2) is called. The list becomes [4, 5, 7]. i increments to 3.
• i = 3: The loop condition i < values.size() is now 3 < 3, which is false. The loop terminates.

The final state of values is [4, 5, 7].

Choice A is what you might expect if the code worked perfectly and removed all even numbers. To do that correctly, you should iterate backward from values.size() - 1 down to 0, or use an Iterator.

This question is a direct application of De Morgan's Laws, which are essential for manipulating boolean expressions. De Morgan's Laws state:

1. !(A && B) is equivalent to !A || !B
2. !(A || B) is equivalent to !A && !B

In our problem, we have !(x > 5 && y <= 10). Let's identify our A and B:

• A is (x > 5)
• B is (y <= 10)

Applying the first law, !(A && B) becomes !A || !B.

• !A is !(x > 5), which is x <= 5.
• !B is !(y <= 10), which is y > 10.

Putting it together with the || (OR), we get x <= 5 || y > 10.

This is a place where you need to be very careful with the details. A common mistake is to forget to flip the && to an || (Choice B), or to get the negations wrong, like mixing up < with <= (Choice C).

Let's remember how insertion sort works. It builds the final sorted array one item at a time. For each pass i, it takes the element at index i and 'inserts' it into its correct place within the already sorted portion of the array (from index 0 to i-1).

The state of the array after the 3rd pass is [3, 5, 8, 9, 2]. The sorted portion is [3, 5, 8, 9]. The next element to consider is at index 4, which is 2.

For the 4th pass, we take the element 2 and find its correct place in the sorted part [3, 5, 8, 9]. The 2 needs to move all the way to the beginning. The other elements (3, 5, 8, 9) will be shifted one position to the right to make room.

The result is [2, 3, 5, 8, 9], which is the fully sorted array.

Choice B is a common mistake if you confuse insertion sort with selection sort. Selection sort would have found the 2 and swapped it with the element at index 4, which is 9, resulting in [3, 5, 8, 2, 9]. But insertion sort shifts elements, it doesn't just swap with the current position.

This question gets at the heart of how object references work in Java. It's a concept called aliasing.

When you write ScoreKeeper teamA = new ScoreKeeper();, you create a new ScoreKeeper object in memory, and the variable teamA holds the memory address of that object. Think of teamA as a label pointing to the object.

When you then write ScoreKeeper teamB = teamA;, you are not creating a new object. You are creating a second label, teamB, and telling it to point to the exact same object that teamA points to.

So, teamA and teamB are two different names for the same thing. When you execute teamB.score = 100;, you are changing the score variable of that one object. Since teamA still points to that same object, asking for teamA.score will give you the new value, 100.

The most common incorrect answer is A, which comes from thinking that teamB = teamA creates a separate copy of the object. It does not!

This question tests the difference between static (class) members and instance (object) members.

• static members belong to the class itself. You can access them using the class name, like Game.totalGamesPlayed or Game.getTotalGames().
• Instance members belong to a specific object (an instance of the class). You need to create an object first to access them, like g2.score or g2.getScore().

Let's analyze the choices:

• A: This is valid. Although it's better style to call a static method using the class name (Game.getTotalGames()), Java allows you to call it on an instance (g1.getTotalGames()). It won't cause a compile error.
• B: This is the standard, correct way to call a static method. It's valid.
• C: This is the standard, correct way to call an instance method. You create an instance g2 and then call getScore() on it. It's valid.
• D: This is the error. getScore() is an instance method. It needs to know which game's score to return. You cannot call it on the Game class itself. You must call it on an object, like g1.getScore() or g2.getScore(). Trying to access an instance method from a static context (using the class name) will result in a compile-time error.

This code is designed to sum the elements along one of the diagonals of a square matrix. Let's trace the loop to see which one.

The matrix mat is: { {10, 20, 30}, {40, 50, 60}, {70, 80, 90} }

mat.length is 3, which is the number of rows.

The loop runs for i = 0, 1, and 2. The expression for the column index is mat.length - 1 - i, which is 3 - 1 - i, or 2 - i.

• i = 0: It adds mat[0][2 - 0], which is mat[0][2] or 30. sum is 30.
• i = 1: It adds mat[1][2 - 1], which is mat[1][1] or 50. sum is 30 + 50 = 80.
• i = 2: It adds mat[2][2 - 2], which is mat[2][0] or 70. sum is 80 + 70 = 150.

This is the sum of the anti-diagonal (from top-right to bottom-left). The final sum is 150.

Choice B (120) is the sum of the middle column. Choice C (90) is the value of the last element. A common mistake is to sum the main diagonal (mat[i][i]), which would be 10 + 50 + 90 = 150. In this specific case, both diagonals happen to have the same sum, but it's crucial to trace the correct one!

This is a fantastic question about short-circuit evaluation, a key feature of Java's logical operators.

Let's look at the first if statement: if (s == null || s.length() > 5).

• The first part, s == null, is evaluated. Since s is null, this is true.
• Because this is an || (OR) expression, if the first part is true, the entire expression must be true. Java is efficient and knows this, so it does not evaluate the second part, s.length() > 5. This is called short-circuiting. If it had tried to evaluate s.length(), it would have thrown a NullPointerException!
• Since the condition is true, count is incremented to 1.

Now for the second if statement: if (s != null && s.length() > 0).

• The first part, s != null, is evaluated. This is false.
• Because this is an && (AND) expression, if the first part is false, the entire expression must be false. Again, Java short-circuits and does not evaluate the second part.
• Since the condition is false, the code inside the if block is skipped. count remains 1.

Finally, System.out.println(count); prints the final value of count, which is 1. The big trap here is choice D. If you don't know about short-circuiting, you would expect s.length() to cause a NullPointerException.

This question tests two fundamental arithmetic operators in Java: integer division (/) and modulo (%).

• a / b: Since both a and b are int variables, this is integer division. 25 / 10 evaluates to 2. The fractional part (.5) is simply discarded, not rounded. So the result is 2.
• a % b: The modulo operator gives the remainder of a division. 25 divided by 10 is 2 with a remainder of 5. So, 25 % 10 is 5.

The println statement concatenates these results with a space in between, so the output is 2 5.

A common mistake is to think a / b will produce a double like 2.5 because that's the mathematical answer. But in Java, the type of the result depends on the types of the operands. int / int always results in an int.

This question compares the efficiency of two fundamental search algorithms.

• Sequential Search: In the worst-case scenario (the item is at the very end of the array or not in the array at all), sequential search must look at every single element. For an array of size n, this is n comparisons.

• Binary Search: This is a much more efficient algorithm, but it requires the array to be sorted. It works by repeatedly dividing the search interval in half. If you have n items, the first comparison cuts the problem size to n/2, the second to n/4, and so on. The number of times you can divide n by 2 until you get to 1 is given by the logarithm base 2 of n, or log₂(n). This is a dramatically smaller number than n for large n.

Therefore, binary search takes approximately log₂(n) comparisons in the worst case, while sequential search takes n. Choice B correctly identifies this relationship. Choice A incorrectly states the number of comparisons for binary search. Choice D swaps the efficiencies, and Choice C incorrectly claims both are the same, ignoring the power of binary search.

This question is about constructor overloading and how one constructor can call another using this().

Let's look at the constructors:

1. public Gadget(String name): This is a one-parameter constructor. Its only job is to call the other constructor, passing along the name it received and a default version of 1. The line this(name, 1); is a call to the two-parameter constructor from within the one-parameter constructor.
2. public Gadget(String name, int version): This is a two-parameter constructor that directly initializes the instance variables.

We want to create a Gadget with name "Phone" and version 1.

• Choice A: new Gadget("Phone") calls the one-parameter constructor. That constructor then immediately calls the two-parameter constructor as new Gadget("Phone", 1). This sets the name to "Phone" and the version to 1. This is exactly what we want.
• Choice B: This would create a gadget with version 0, not 1.
• Choice C: This would not compile because the instance variables name and version are private, so they cannot be accessed directly from outside the class. Also, there is no no-argument constructor Gadget() defined.
• Choice D: This would not compile because there is no constructor that takes an int and then a String. The order of parameters matters.

This is a very tricky question that hinges on a specific implementation detail of Java's wrapper classes. It's about the difference between comparing object references (==) and comparing their actual values (.equals()).

When you write Integer a = 150;, Java uses a process called autoboxing to convert the int literal 150 into an Integer object. It's equivalent to Integer a = Integer.valueOf(150);.

Here's the secret: to save memory, Java maintains a cache of Integer objects for small integer values. By default, this cache is for values from -128 to 127.

• c == d: Both c and d are assigned the value 100. Since 100 is within the cached range [-128, 127], Java gives both c and d a reference to the exact same pre-existing Integer object from the cache. Therefore, c == d compares two references pointing to the same object, and the result is true.

• a == b: Both a and b are assigned the value 150. This value is outside the cached range. Because of this, Java creates a new Integer(150) for a and a separate new Integer(150) for b. They have the same value, but they are two different objects in memory. Therefore, a == b compares two references pointing to different objects, and the result is false.

The output is false, true. This is a classic AP exam trap! The safe way to compare wrapper objects for equality is to always use the .equals() method, as in a.equals(b), which would be true.

A for loop is really just a compact way of writing a certain kind of while loop. A for loop has three parts: for (initialization; condition; update).

Let's break down the given while loop:

• Initialization: int k = 2; (This happens before the loop starts.)
• Condition: k <= 10 (This is checked at the beginning of each iteration.)
• Update: k += 2; (This happens at the end of each iteration.)

To create an equivalent for loop, we just need to place these three parts in the correct spots.

for (int k = 2; k <= 10; k += 2)

This matches the logic of the while loop perfectly. The loop will start with k=2, continue as long as k is less than or equal to 10, and add 2 to k after each time through. This makes Choice C the correct answer.

• Choice A has the wrong condition (k < 10), so it would not print the final 10.
• Choice B has the wrong update step (k++), so it would print 2 3 4 5 6 7 8 9 10.
• Choice D has the wrong initialization (k = 0), so it would start by printing 0.

Let's trace the execution carefully. The findBook method searches the myBooks array for a book with the title "Hyperion".

1. The myBooks array contains books titled "Dune" and "Foundation".
2. The findBook method loops through the array. It checks "Dune", which doesn't match "Hyperion". It checks "Foundation", which also doesn't match.
3. The loop finishes without finding a match. The method then executes its final line: return null;.
4. The variable found in the calling code is assigned the value null.
5. The next line is System.out.println(found.getTitle());. Here's the problem. You are trying to call the getTitle() method on the found variable, which currently holds null. You can't call a method on null! It's like trying to ask a question to someone who isn't there.

This action causes a NullPointerException at runtime. Choice C is a tempting distractor, as null is what's inside the found variable, but the code doesn't just print the variable—it tries to use it, which causes the error.

This is a classic array manipulation problem. We need to shift every element to the left. Let's think about the goal: data[0] should get the value of data[1], data[1] should get data[2], and so on.

The first step correctly saves the first element: int first = data[0]; (so first is 10). Now we need to perform the shift.

Let's analyze the loops:

• Choice A: data[i] = data[i - 1];. Let's trace it. When i=1, data[1] becomes data[0] (so data is {10, 10, 30, 40}). When i=2, data[2] becomes data[1] (which is now 10, so data is {10, 10, 10, 40}). This loop copies the first element into all the other spots. Incorrect.

• Choice B: data[i] = data[i + 1];. Let's trace. When i=0, data[0] becomes data[1] (so data is {20, 20, 30, 40}). When i=1, data[1] becomes data[2] (so data is {20, 30, 30, 40}). When i=2, data[2] becomes data[3] (so data is {20, 30, 40, 40}). The loop stops. The array is {20, 30, 40, 40}. Finally, data[data.length - 1] = first; sets the last element to 10. The final array is {20, 30, 40, 10}. This works perfectly.

• Choice C: This is similar to B but iterates backward. It would also work correctly. However, the question asks which loop works, and B is a valid forward-iterating solution.

• Choice D: data[i - 1] = data[i];. When i=0, this attempts to access data[-1], which will cause an ArrayIndexOutOfBoundsException.

Both B and C are logically correct ways to perform the shift. However, in the context of typical AP questions, the forward iteration (B) is the most direct implementation of the left shift.

This question is about informal run-time analysis, often called Big O notation. We're comparing how the execution time grows as the input size n gets very large.

• Choice A: A single loop that runs from 0 to n. The number of operations is directly proportional to n. We call this linear time, or O(n).

• Choice B: A nested loop. The outer loop runs n times, and for each of those times, the inner loop also runs n times. The total number of operations is n * n, or n². We call this quadratic time, or O(n²).

• Choice C: A single loop that runs from 0 to n/2. While it does half the work of the loop in Choice A, its run time is still directly proportional to n. For large n, the constant factor of 1/2 becomes insignificant. This is also O(n).

• Choice D: A loop that runs a million times. This might seem like a lot, but the number of iterations is constant. It does not change even if n becomes a billion. We call this constant time, or O(1).

When comparing these for very large n, a quadratic function (n²) will always grow much, much faster than a linear function (n) or a constant function. Therefore, the nested loop in Choice B will take the longest to execute.