Chapter 15 ■ OCPJP 7 Quick Refresher

•The Visitor design pattern is used to enable walking through a file tree.

•In the context of a watch service, a state is associated with a watch key. A watch key might be in ready state (ready to accept events), in signed state (when one or more events are queued), or in invalid state (when the watch key is not valid). If the key is in the signed state, it is required to call the reset() method; otherwise the state of the key will not change to ready state and you will not receive any further event notification.

•If you are watching a directory using the watch service offered by Java 7, only files contained in that directory will be watched—and not the files contained in the subdirectories of that directory. If you intend to watch the whole subtree of the file system, you need to recursively register each directory in the subtree.

Chapter 10: Building Database Applications with JDBC

•JDBC (Java DataBase Connectivity) APIs provided by Java are meant for programmatic access to DataBase Management Systems (DBMSs).

•JDBC hides all the heterogeneity of all the DBMSs and offers a single set of APIs to interact with all types of databases. The complexity of heterogeneous interactions is delegated to the JDBC driver manager and JDBC drivers; hence all the details and complications are hidden by the JDBC API from the application developer.

•There are four types of drivers:

•Type 1 (JDBC-ODBC bridge drivers): The JDBC driver calls ODBC (Open Database Connectivity) native calls using the Java Native Interface (JNI).

•Type 2 (Native-API drivers): These drivers use client-side libraries of a specific database and convert JDBC calls to native database calls.

•Type 3 (Network-protocol drivers): These drivers call database middleware, and the middleware actually converts JDBC calls to database-specific native calls.

•Type 4 (Native-protocol drivers): The driver directly makes database-specific calls over the network without any support of an additional client-side library.

•The java.sql.Connection interface provides a channel through which the application and the database communicate. The getConnection() method in the DriverManager class takes three arguments: the URL string, username string, and password string.

•The syntax of the URL (which needs to be specified to get Connection object) is

<protocol>:<subprotocol>://<server>:<port>/. An example of URL string is jdbc:mysql://localhost:3306/. The <protocol> jdbc is same for all DBMSs; <subprotocol> will differ for each DBMS, <server> depends on the location in which you host the database, and each DBMS uses a specific <port> number.

•If the JDBC API is not able to locate the JDBC driver, it will throw a SQLException. If there are jars for the drivers available, they need to be included in the classpath to enable the JDBC API to locate the driver.

•Prior to JDBC 4.0, you had to explicitly load the JDBC driver using the Class.forName() statement; with JDBC 4.0 and above, this statement is not needed and JDBC API will load the driver from the details given in the URL string.

•JDBC supports two classes for querying and updating: Statement and Resultset.

496

Chapter 15 ■ OCPJP 7 Quick Refresher

•A Statement is a SQL statement that can be used to communicate a SQL statement to the connected database and receive results from the database. There are three types of Statements:

•Statement: Use Statement when you need to send a SQL statement to the database without any parameter.

•PreparedStatement: Represents a precompiled SQL statement that can be customized using IN parameters.

•CallableStatement: Used to execute stored procedures; can handle IN as well as OUT and INOUT parameters.

•Choose the proper execute method based on the type of the SQL statement. Remember that each execute method returns different output. The method executeQuery() returns a resultset; executeUpdate() returns an update count; and the execute() method may return multiple resultsets, or multiple update count, or combination of both.

•A Statement object closes the current ResultSet object if a) the Statement object is closed, b) is re-executed, or c) is made to retrieve the next set of result. That means it is not necessary to call close() explicitly with the ResultSet object; however, it is good practice to call close() once you are done with the object.

•It is your responsibility to issue a correct SQL command; JDBC Statement will not check for its correctness. For example, if there is a syntax error in the SQL command string, you will not get a compiler error. Rather, you’ll get a SQLSyntaxErrorException at runtime.

•A ResultSet object maintains a cursor pointing to the current row. Initially, the cursor is set to just before the first row; calling the next() method advances the cursor position by one row.

•You can use column name or column index with ResultSet methods. The index you use is the index of the ResultSet object, not the column number in the database table.

•The column index in the ResultSet object starts from 1 (not from 0).

•You may use the column name of a ResultSet object without worrying about the case: getXXX() methods accept case-insensitive column names to retrieve the associated value.

•Think of a case when you have two columns in a ResultSet object with the same name. How you can retrieve the associated values using the column name? If you use column name to retrieve the value, it will always point to the first column that matches with the given name. Hence, you have to use column index in this case to retrieve values associated with the both columns.

•You need to call updateRow() after modifying the row contents in a ResultSet; otherwise changes made to the ResultSet object will be lost.

•You may cancel any update you made using the method cancelRowUpdates(). However, you must call this method before calling the method updateRow(). In all other cases, it has no impact on the row.

•By calling the getMetaData() method in the Connection interface, you can examine the capabilities of the underlying database.

•A transaction is a set of SQL operations that needs to be either executed all successfully or not at all.

497

Chapter 15 ■ OCPJP 7 Quick Refresher

•By default auto-commit mode is set to true, so all changes you make through the connection are committed automatically to the database. You can use setAutoCommit(false); to enable manual commits. With auto-commit not enabled, you need to explicitly commit or rollback transactions.

•If the commit() method does not execute in manual commit mode, there will be no change in the database.

•You can divide a big transaction into multiple milestones. These milestones are referred to as Savepoints. This way you may save the changes to database up to a milestone once the milestone is achieved.

•RowSet is a special ResultSet that supports the JavaBean component model. Figure 15-2 summarizes the RowSet hierarchy and associated key capabilities.

ResultSet

RowSet

ResultSet capabilities+ Java Bean capabilities+

JdbcRowSet CachedRowSet disconnected ResultSet capabilities

Figure 15-2.  The RowSet hierarchy

•JdbcRowSet is a connected RowSet while other subinterfaces of RowSet (i.e., JoinRowSet, CachedRowSet, WebRowSet, and FilteredRowSet) are disconnected RowSets.

•RowSetProvider provides APIs to get the RowSetFactory implementation, which can in turn be used to instantiate a relevant RowSet implementation.

•JDBC 4.1 introduces the capability to use try-with-resources statement to close resources (Connection, ResultSet, and Statement) automatically.

498

Chapter 15 ■ OCPJP 7 Quick Refresher

Chapter 11: Exceptions and Assertions

•While providing multiple exception handlers (“stacked” catch handlers), specific exception handlers should be provided before general exception handlers. Providing base exception handlers before the derived handlers will result in a compiler error.

•A try block can have multiple catch handlers. If the cause of two or more exceptions is similar and the handling code is also similar, you can consider combining the handlers and make it into a multi-catch block.

•The code inside a finally block will be executed irrespective of whether a try block has successfully executed or resulted in an exception. This makes a finally block the most suitable place to release resources such as file handles, data base handles, network streams, etc.

•In a multi-catch block, you cannot combine catch handlers for two exceptions that share a baseand derived-class relationship. You can only combine catch handlers for exceptions that do not share the parent-child inheritance relationship between them.

•Forgetting to release resources by explicitly calling the close() method is a common mistake. You can use a try-with-resources statement to simplify your code and auto-close resources. For a resource to be usable in a try-with-resources statement, the class of that resource must implement the java.lang.AutoCloseable interface and define the close() method.

•You can auto-close multiple resources within a try-with-resources statement. These resources need to be separated by semicolons in the try-with-resources statement header.

•Because you can use multiple resources within a try-with-resources statement, the possibility of more than one exception getting thrown from both the try block and the finally block is high. If a try block throws an exception, and a finally block also throws exception(s), then the exception(s) thrown in the finally block will be added as suppressed exceptions to the exception that gets thrown out of the try block to the caller.

•You cannot assign to the resource variables declared in the try-with-resources within the body of the try-with-resources statement. This is to make sure that the same resources acquired in the try-with-resources header are released in the finally block.

•It is a common mistake to close a resource explicitly inside the try-with-resources statement. Remember that try-with-resources expands to calling the close() method in the finally block, so if you provide an explicit call to the close() method in the finally block, the expanded finally block will effectively have a double call to the close() method.

•The class Throwable is the root class of the exception hierarchy. Only Throwable and its derived classes can be used with Java exception handling keywords such as try, catch,and throws.

•The Exception class (except its subhierarchy of the RuntimeException class) and its derived classes are known as checked exceptions. These exceptions represent exceptional conditions that can be “reasonably expected” to occur when the program executes and thus must be handled. A method that contains some code segment that can throw a checked exception must either provide a catch handler to handle it or declare that exception in its throws clause.

•The RuntimeException and Error classes and derived classes are known as unchecked exceptions. They can be thrown anywhere in the program (without being declared that the segment of code can throw these exceptions).

•The RuntimeException classes and derived classes represent programming mistakes (logical mistakes) and are not generally expected to be caught and handled in the program. However, in some cases it is meaningful to handle these exceptions in catch blocks.

499

Chapter 15 ■ OCPJP 7 Quick Refresher

•The Error classes and derived classes represent exceptions that arise because of JVM errors— either the JVM has detected a serious abnormal condition or has run out of resources. When an Error occurs, the typical best course of action is to terminate the program.

•A catch block should either handle the exception or rethrow it. To hide or swallow an exception by catching an exception and doing nothing is really a bad practice.

•The throws clause for a method is meant for listing the checked exceptions that the method body can throw.

•Static initialization blocks cannot throw any checked exceptions. Non-static initialization blocks can throw checked exceptions; however, all the constructors should declare that exception in their throws clause.

•A method’s throws clause is part of the contract that its overriding methods in derived classes should obey. An overriding method can provide the same throw clause as the base method’s throws clause or a more specific throws clause than the base method’s throws clause. The overriding method cannot provide a more general throws clause or declare to throw additional checked exceptions when compared to the base method’s throws clause.

•If a method does not have a throws clause, it does not mean it cannot throw any exceptions—it just means it cannot throw any checked exceptions.

•It is a bad practice to use a throws clause to list unchecked exceptions that a method may throw. Why? Since the compiler cannot force the callers to handle unchecked exceptions, it does not make sense to list them in the throws clause. Rather, if a method can throw an unchecked exception, it is better to use the @throws clause to document that possibility.

•Non-static initialization blocks can throw checked exceptions; however, all the constructors should declare those exceptions in their throws clause. Why? The compiler merges the code for non-static initialization blocks and constructors during its code generation phase, so the throws clause of the constructor can be used to declare the checked exceptions that a nonstatic initialization block can throw.

•An overriding method cannot declare more exceptions in the throws clause than the list of exceptions declared in the throws clause of the base method. Why? The callers of the base method see only the list of the exceptions given in the throws clause of that method and will declare or handle these checked exceptions in their code (and not more than that).

•An overriding method can declare more specific exceptions than the exception(s) listed in the throws clause of the base method; in other words, you can declare derived exceptions in the throws clause of the overriding method.

•If a method is declared in two or more interfaces and if that method declares to throw different exceptions in the throws clause, then the implementation should list all these exceptions in its throws clause.

•You can define your own exception classes (known as custom exceptions) in your programs.

•It is recommended that you derive custom exceptions from either the Exception or RuntimeException class. Creation of custom exceptions by extending the Throwable class (too generic) or the Error class (exceptions of this type are reserved for JVM and the Java APIs to throw) is not recommended.

•You can wrap one exception and throw it as another exception. These two exceptions become chained exceptions. From the thrown exception, you can get the cause of the exception.

•Assertions are condition checks in the program and are meant to be used to explicitly check the assumptions you make while writing programs.

500