Java Core Classes and Threads

Java reserves goto and const as keywords but doesn't use them. 'inner' was reserved for potential inner class support but ultimately wasn't used (inner classes use different syntax). Union, boolean, and synchronized are used keywords.

Java exceptions are objects thrown using the 'throw' keyword with 'new' to instantiate the exception class. Option B shows correct syntax: 'throw new IndexOutOfBoundsException(...)' creates the exception object and throws it. Option A uses 'throws' (a declaration keyword, not for throwing) and has a typo. Option C tries to throw a string literal directly, which isn't valid - only Throwable objects can be thrown.

Java has robust built-in support for multithreaded programming through the Thread class, Runnable interface, and synchronized keyword. The language was designed from the ground up to support concurrent programming, making it one of the core strengths of the Java platform.

In Hibernate, the default lazy loading behavior is 'lazy=true' for collections and associations. This means related objects are loaded only when actually accessed, not eagerly. Options A, C (lazy=yes is invalid syntax), and D are incorrect.

In Hibernate, Session.get() immediately hits the database and returns null if the record does not exist. Session.load() returns a proxy and throws an exception later if the entity is missing, making get() safer when existence is uncertain.

Overloaded methods are distinct methods and can throw any checked exceptions. However, overridden methods in subclasses cannot throw new or broader checked exceptions than the original method. Thus, the statement is false.

Hibernate requires choosing one inheritance strategy per hierarchy. You cannot mix table-per-class (union subclass) and table-per-subclass (joined subclass) within the same hierarchy. Each persistent hierarchy must use a single strategy.

In Hibernate, lazy loading is enabled by default (lazy=true) for associations and collections to optimize performance by avoiding loading related entities until they are explicitly accessed.

In Hibernate, making a property read-only from the application side (while still loading it from the database) is achieved by setting insert="false" and update="false" in the mapping XML or annotations. This tells Hibernate to retrieve the property value when loading objects but never include it in INSERT or UPDATE statements. Option A correctly states this. Options B and C use incorrect attribute names (should be 'insert' and 'update', not 'isinsert' and 'isupdate'), making them invalid.

Session.get() is the better choice when you're uncertain whether a row exists. The get() method returns null if no matching row is found, allowing you to handle the absence gracefully. In contrast, Session.load() assumes the row exists and throws an ObjectNotFoundException if it doesn't, which would cause an uncaught exception in your code. Option B is correct. Options C and D are incorrect because there's no Session.fetch() method in standard Hibernate, and load() would cause an exception.

To solve this question, the user needs to have knowledge about the concept of a bag data structure. A bag is a collection of unordered elements that may contain duplicates.

Now, let's go through each option and explain why it is right or wrong:

a) bag has index column: This statement is incorrect. A bag is an unordered collection, which means it does not have an index column. Items in a bag are stored in any order.

b) bag permits duplicate element values: This statement is correct. A bag allows duplicate elements to be added to it. For example, a bag can contain two or more items with the same value.

c) bag does not permit duplicate element values: This statement is incorrect. A bag permits duplicate elements to be added to it. Therefore, this statement is false.

d) None: This option is incorrect because option B is correct.

The Answer is: B

The refresh() method re-loads an object and all its collections from the database, overwriting the current state in the Session. This is particularly useful when database triggers initialize or modify properties after the initial save - refresh() retrieves those trigger-generated values. Option A correctly identifies refresh(). Option B (flush) synchronizes the Session state to the database (writes to DB, not reads from it). Options C and D are incorrect because there's no standard fetch() method, and load() retrieves only if already in Session or throws exception.