Java Core Classes and Threads

Of the options, 'extend' is not a Java keyword. 'assert' (A), 'interface' (B), and 'transient' (D) are all valid Java keywords. 'extend' might be confused with 'extends', which IS a keyword for inheritance, but 'extend' by itself is not a Java reserved word.

In PL/SQL, you handle exceptions by either trapping them locally using an exception handler block, or by allowing them to propagate unhandled to the calling environment to be managed at a higher level.

To retrieve information from a ResultSet, the user needs to know the methods that can be used to access the data. A ResultSet is a table of data that represents the results of a database query.

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

A. O (a) By invoking the method get (..., String type) on the ResultSet, where type is the database

This option is incorrect because there is no method get (..., String type) in ResultSet. The method get() can be used to retrieve data from the ResultSet, but it requires the index or the name of the column. The String type parameter is not valid.

B. O (b) By invoking the method get (..., Type type) on the ResultSet, where Type is an object

This option is incorrect because there is no method get (..., Type type) in ResultSet. The method get() can be used to retrieve data from the ResultSet, but it requires the index or the name of the column. The Type type parameter is not valid.

C. O (c) By invoking the method getValue (...), and cast the result to the desired java type.

This option is incorrect because there is no method getValue() in ResultSet. The method get() can be used to retrieve data from the ResultSet, but it requires the index or the name of the column. Additionally, the method get() returns an object that needs to be cast to the desired data type.

D. O (d) By invoking the special getter methods on the ResultSet: getString (...), get Boolean (...),

This option is correct. ResultSet provides special getter methods such as getString(), getInt(), getBoolean(), etc. that can be used to retrieve data from the ResultSet. These methods take the index or the name of the column as a parameter and return the value of the column as the desired data type.

The Answer is: D

To answer this question, the user needs to have a basic understanding of Java Database Connectivity (JDBC) and ResultSet objects.

Option A is incorrect. The close() method does exist for ResultSet objects.

Option B is correct. If you call the close() method on a ResultSet object, the resources associated with the ResultSet will be released and returned to the database. This includes any database and JDBC resources that were used to create the ResultSet.

Option C is incorrect. The close() method can be called on a ResultSet object, but not on a Statement object. It is the Statement object that creates the ResultSet.

Option D is incorrect. While the ResultSet is associated with the Statement and Connection objects that created it, calling the close() method on the ResultSet will only release the resources associated with the ResultSet itself, not the Statement or Connection objects.

Therefore, the answer is: B. O (b) the database and JDBC resources are released.

The correct answer to the question is B. The row you are positioned on is deleted from the ResultSet and from the database.

The deleteRow() method of the ResultSet interface deletes the current row from the ResultSet object and from the underlying database table. This means that the row will no longer be visible in the ResultSet object, and it will also be deleted from the database.

The deleteRow() method only works if the ResultSet object is updatable. An updatable ResultSet object is one that can be used to modify data in the database. To create an updatable ResultSet object, you must set the CONCUR_UPDATABLE property of the Statement object that you use to execute the query.

The deleteRow() method does not throw any exceptions. If you try to delete a row from a ResultSet object that is not updatable, the method will simply do nothing.

Here is an example of how to use the deleteRow() method:

import java.sql.*;

public class DeleteRowExample {

    public static void main(String[] args) throws SQLException {
        Connection connection = DriverManager.getConnection("jdbc:mysql://localhost/mydatabase", "username", "password");
        Statement statement = connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE);
        String sql = "SELECT * FROM customers";
        ResultSet resultSet = statement.executeQuery(sql);

        // Move the cursor to the first row.
        resultSet.first();

        // Delete the current row.
        resultSet.deleteRow();

        // Close the connection.
        connection.close();
    }
}

This code will delete the first row in the customers table.

The getLastModified() method in HttpServlet returns a long value representing milliseconds since the epoch (January 1, 1970). This matches the Last-Modified HTTP header format. It does not return java.util.Date or java.sql.Date objects, nor does it return an int. Option D is correct.

PageContext.findAttribute(String name) searches for an attribute across all four scopes in order: page, request, session, and application. It returns the first match found or null if not found in any scope. Option B correctly describes this behavior. Option C is wrong because it's not limited to page scope only.

The HttpServletRequest interface specifies getHeaderNames() which returns an Enumeration of String header names. Option A is correct. Option B is wrong because getHeaders(String) returns an Enumeration of String values (all values for a multi-value header), not a String array. Option C is incorrect because getHeaderValues is not a standard method (likely confused with getHeaders). Option D is wrong because there's no getIntParameter method (use getParameter() then parseInt).

In JSP custom tags with body content, the JSP container manages out/out nesting using pushBody() and popBody(). pushBody() is called after doStartTag() and before doInitBody/doAfterBody to save the current out. popBody() is called after doAfterBody() and before doEndTag to restore the previous out. Options A and C correctly describe this lifecycle. The timing in options B and D is incorrect.

To sort the keys from a HashMap, you can create a TreeSet from the keySet() - TreeSet automatically sorts elements using their natural ordering (alphabetical for strings). Arrays.sort() doesn't work on Sets directly, Collections.sort() works on Lists, and SortedSet is an interface that cannot be instantiated directly. Option B correctly uses TreeSet to achieve sorting.

Thread execution is non-deterministic. Either main prints "End of method." first (option D), or the thread prints "run." first (option E). The RuntimeException is uncaught in the thread so it just terminates after printing. Options A, B, C are not valid output patterns.

The count field is mutable and accessed by reset(), getCount(), and increment(). These need synchronization to prevent race conditions. getName() only reads immutable 'name', and constructors don't need sync as the object isn't shared yet.

When ResourceException is thrown on line 86, execution jumps to the catch block at line 89. Line 88 (con.close()) is skipped, leaving the connection unclosed. This is a resource leak.