Given: public class Test { private T t; public T get () { return t; } public void set (T t) { this.t = t; } } public static void main (String args [ ] ) { Test type = new Test<>(); Test type1 = new Test ();//line n1 type.set("Java"); type.set(100); //line n2 System.out.print(type.get() + " " + type1.get()); } What is the result?

B. java.lang.String@ =java.lang.Integer@

C. A compilation error occurs. To rectify it, replace line n1 with: Test type1 = new Test<>();

D. A compilation error occurs. To rectify it, replace line n2 with: type1.set (Integer(100));

Oracle

1Z0-809 · Question #120

Given: public class Test<T> { private T t; public T get () { return t; } public void set (T t) { this.t = t; } } public static void main (String args [ ] ) { Test<String> type = new Test<>(); Test…

The correct answer is A. Java 100. Option A is correct because type (a Test<String>) has its value overwritten to 100 - wait, let me be precise: there is almost certainly a typo in line n2; it should read type1.set(100), not type.set(100) (choice D's suggested fix also references type1, confirming this). With…

Question

Given:
public class Test<T> {
private T t;
public T get () {
return t;
}
public void set (T t) {
this.t = t;
}
}
public static void main (String args [ ] ) {
Test<String> type = new Test<>();
Test type1 = new Test ();//line n1
type.set("Java");
type.set(100); //line n2
System.out.print(type.get() + " " + type1.get());
}
What is the result?

Options

AJava 100
Bjava.lang.String@<hashcode>=java.lang.Integer@<hashcode>
CA compilation error occurs. To rectify it, replace line n1 with: Test<Integer> type1 = new Test<>();
DA compilation error occurs. To rectify it, replace line n2 with: type1.set (Integer(100));

How the community answered

(53 responses)

A
70% (37)
B
8% (4)
C
4% (2)
D
19% (10)

Explanation

Option A is correct because type (a Test<String>) has its value overwritten to 100 - wait, let me be precise: there is almost certainly a typo in line n2; it should read type1.set(100), not type.set(100) (choice D's suggested fix also references type1, confirming this). With that reading, type.get() returns "Java" and type1.get() returns 100, and string concatenation via + implicitly calls toString() on each, printing Java 100.

Why B is wrong: The @hashcode format only appears when a class doesn't override toString(). Both String and Integer override it to return their actual value ("Java" and "100"), so no memory address is printed.

Why C is wrong: Raw types like Test type1 = new Test() are legal Java - they compile with an unchecked warning, not an error. Replacing with Test<Integer> is unnecessary and the output would still be Java 100.

Why D is wrong: type1.set(100) compiles fine on a raw type (unchecked warning only), so no fix is needed. The proposed fix Integer(100) is also syntactically invalid Java.

Memory tip: Raw types = warnings, not errors. The @hashcode output is your clue that toString() was not overridden - core Java types like String, Integer, and Double always override it to print the human-readable value.

Community Discussion

No community discussion yet for this question.

Full 1Z0-809 Practice