|
|
1. þ D E
D and E are correct. The List interface represent collection that maintain order among elements and the element are not necessarily unique. Therefore, the classes ( ArrayList and Vector) that implements List, can represent an ordered collection of non-unique elements.
A is incorrect as Arrays is a utility class, it does not represent collection. B is incorrect as List is an interface(Note the question asks about ‘classes’). C is incorrect as HashSet is a collection of unique elements. F is incorrect as Hashtable cannot maintain order.
2. þ ADE
The correct answers are A, D and E. All of the collection classes have ability to automatically grow their size as elements are added. However, only the collections of List type allow the indexed access. The classes LinkedList, ArrayList and Vector implement List interface and hence they allow indexed access to their element which means you can access element by providing its position (index).
B and C are incorrect. B is incorrect, as List is an interface. (Note that the question asks about ‘classes’). C is incorrect as HashSet do not provide an indexed access to its elements.
3. þ E
The correct answer is E. The Hashtable class stores key-value mappings and provides thread-safe synchronized access to its elements.
B C and D are incorrect. They all represent a map which stores the key-value mappings but they are not thread safe. A is incorrect as LinkedHashSet is collection of unique elements. It does not store key-value mappings.
4. þ E
The correct answer is E. This code will not compile, note that you cannot store primitives directly in the collections. The collections accept only objects as their elements. If at all you want to store primitives, you need to wrap them first in appropriate wrapper and then store the wrapper object as element.
A B C and D are all incorrect. The code will not compile at lines 5,6,7,8 and 9. Even the cast at line 12 is invalid. Iterator returns object of Object type. You cannot cast it primitive type int.
5. þ E
The correct answer is E. None of the statements are true.
A is incorrect. When you try to add a duplicate element, nothing happens. The Set simply ignores the new element. UnsupportedOperationException is thrown when you invoke some optional method on collection which is not implemented by it. Note that this is a runtime exception hence you need not handle it. Hence, D is incorrect.
6. þ B
Only maps are capable of associating an element with a key. Option B, C and D all represent maps. But only the LinkedHashMap guarantees a predictable order of its elements. It can maintain two types of order within elements. Elements are either in the order in which keys were inserted into the map (that is the insertion-order). Alternatively, they can be in the order in which they are accessed. Since the question asks about insertion-order, LinkedHashMap is the correct choice.
C and D are incorrect. HashMap does not guarantee any order for elements. TreeMap guarantees that elements will be in ascending order of keys. A, E and F are incorrect as they do not store key-value mappings.
7. þ C D
C and D are correct. Since the out put is “1 3”, we know that car1.equals(car2) and car3.equals(car4) are true. The contract between equals() and hashCode is such that if equals() returns true for two objects, the hashCode() must return same number on those two objects. Therefore car1.hashCode() and car2.hashCode() must return same number . Hence C is true. Similarly car3.hashCode() and car4.hashCode() must return same number . Hence D is true.
A is not guaranteed to be true. Since line 4 returns true car2 and car3 have same hashCode. However having same hashCode does not guarantee that two objects are equal. Hence car2.equals(car3) may or may not return true. B is also not guaranteed, as we do not know the relation between car2 and car3
8. þ A B C
A B and C are correct. Since the output is “1 2 3”, we know that car1.equals(car2) and car2.equals(car3) and car3.equals(car4) are true. The equals() method should follows transitivity. Therefore when car1 equals car2 and car2 equals car3, then car1 equals to car3. Therefore A and B are true. The correctly implemented equals() method is also symmetric. Therefore, when car1 equals car2 and car2 also equals car1, Hence C is also correct.
The contract between equals() and hashCode is such that if equals() returns true for two objects, the hashCode() must return same number on those two objects. Therefore hashCode of car1, car2, car3 and car4 must be same as equals() method returns true on any combination of these objects. Therefore, we can say with guarantee that D and E can never be true.
9. þB
Only B is correct. Both classes have valid definitions of hashCode(). However the hashCode() of Flower2 is likely to return different hashCode when color is different. Therefore when it is stored in collection that uses hashing, it is likely that objects of Flower2 will be widely spread. However, objects of Flower1 will always return constant number. Hence, all objects of Flower1 type will be stored in the same bucket in hashing collection. This results in highly inefficient storage. Hence hashCode() of Flower2 is better that Flower1.
D and E are incorrect. Though hashCode() in Flower1 returns a constant number it is not invalid. Therefore, Flower1 and Flower2 compile successfully.
10. þ A B
A and B are correct. A is correct because when the equals() return true for two instance, the hashCode() must return same value. But the reverse is not necessarily true. If hashCode of two instances return same number does not mean equals() will return true. But since B is indicating a possibility (note the word ‘might’), it is a correct answer.
Options C D and E are all incorrect. hashCode() method has only one restriction, its should return same code for two equal objects. However it is not mandatory that hashCode() return different code for two unequal objects. Hence C is incorrect. Similarly it is also not mandatory that when hashCode() return same code for two objects, they are necessarily equal. Hence D is incorrect as well.
** mention that when you override hashCode you must override equals() as well
11. þ E
Only E is correct statement. The equals() method take an argument of Object type. Hence you can invoke equals() of an object by sending object of different type. Ideally if two objects are not of same type, the equals() method should return false.
A and B are incorrect as the contract between equals() and hashCode() is such that when one is overridden, the other must be overridden as well. C is incorrect. While it is allowed for hashCode() to return same number even for dissimilar object, it is not mandatory (Note the word ‘must’). D is also incorrect for the similar reason. While it is allowed for hashCode() to return different number for dissimilar objects, it must return same number for two equal objects.
12. þ A C D E
A C D and E are correct. The classes String and all wrapper classes override equals() method. Hence they also override the hashCode() method. (Note that classes that override equals() must also override the hashCode() method).
B is incorrect as StringBuffer class does not override the equals() method and hence it does not override the hashCode() method either.