Professional Java.JDK.5.Edition (Wrox)

Chapter 5

}

public void actionPerformed(ActionEvent evt) {

JFileChooser fc = new JFileChooser();

if (JFileChooser.APPROVE_OPTION == fc.showOpenDialog(myApp)) { try {

Once the user has picked the file, you begin the process of unmarshalling the XML data contained in the file to your JAXB-generated data model. The code below shows the XML file the user specified being unmarshalled into a new instance of org.book.configuration.Configuration, the JAXB object representing the root node of the XML document specified in your configuration.xsd schema file:

JAXBContext ctx = JAXBContext.newInstance(ConfigurationType.class

.getPackage().getName());

Unmarshaller u = ctx.createUnmarshaller(); org.book.configuration.Configuration configType =

(org.book.configuration.Configuration) u.unmarshal (fc.getSelectedFile());

Now that the data has been unmarshalled, the data from the JAXB model must be mapped back from the JAXB model to your original book.Configuration model. This is essentially the reverse-process of what occurred in your save action. You are converting things like your JAXB ColorType back into a form that can be displayed in your Swing user interface, the java.awt.Color object. After the data has been mapped into your book.Configuration class, it can then be loaded into the application via the myApp.setConfiguration() method:

Configuration conf = new Configuration();

ColorType bgColorType = configType.getUiSettings().getBackgroundColor(); if (bgColorType != null) {

Color bgColor = new Color(bgColorType.getRed(), bgColorType.getGreen(), bgColorType.getBlue(), bgColorType.getAlpha());

conf.setBackgroundColor(bgColor);

}

ColorType fgColorType = configType.getUiSettings().getForegroundColor(); if (fgColorType != null) {

Color fgColor = new Color(fgColorType.getRed(), fgColorType.getGreen(), fgColorType.getBlue(), fgColorType.getAlpha());

conf.setForegroundColor(fgColor);

}

PointType ppPointType = configType.getUiSettings()

.getPaletteWindowPosition();

if (ppPointType != null) {

276

Persisting Your Application Using Files

Point ppPoint = new Point(ppPointType.getXCoord(), ppPointType.getYCoord());

conf.setPaletteWindowPosition(ppPoint);

}

PointType tpPointType = configType.getUiSettings()

.getToolsWindowPosition();

if (tpPointType != null) {

Point tpPoint = new Point(tpPointType.getXCoord(), tpPointType.getYCoord());

conf.setToolsWindowPosition(tpPoint);

}

conf.setShowTabs(configType.getUiSettings().isShowTabs());

conf.setUserHomeDirectory( configType.getUserSettings().getUserHomeDirectory());

RecentFilesType rFilesType =

configType.getUserSettings().getRecentFiles();

if (rFilesType != null) {

List recentFileList = rFilesType.getRecentFile(); if (recentFileList != null) {

String[] recentFiles = new String[recentFileList.size()];

recentFileList.toArray(recentFiles);

conf.setRecentFiles(recentFiles);

}

}

myApp.setConfiguration(conf);

}catch (JAXBException jaxb) { JOptionPane.showMessageDialog(this.myApp, jaxb.getMessage(), “Error”,

JOptionPane.ERROR_MESSAGE);

jaxb.printStackTrace();

}

}

}

}

Similar to your save action, you must also catch JAXBException. If an error occurs while loading the file, that is, if it does not conform to your configuration.xsd schema or the file could not be found, etc., the exception will be thrown.

277

Chapter 5

The Swing actions you just developed get integrated into your application the same way the previous ones did. Your application now has two mechanisms for persisting its configuration data model. One is user-friendly to edit, the other one cannot be edited outside of the application. JAXB takes more effort on the part of the developer, but can provide added value over normal Java Serialization. Figure 5-17 shows a screen shot of your updated application.

Figure 5-17

When to Use JAXB

JAXB is fundamentally different from either the Java Serialization API or the XMLEncoder/Decoder API. It takes a completely different approach. Instead of first specifying a data structure using Java classes, one first specifies the serialization format itself. The two are drastically different design approaches. In the Java Serialization and XMLEncoder/Decoder API, you design Java classes and do not worry about the serialization file format — that is taken care of by the APIs. However, it has the unfortunate disadvantage of limiting the use of the serialized objects to only Java-based applications. JAXB generates your Java data classes for you (at the expense of a very loose integration of your data with the JDK libraries) from the specification of a file format in a W3C standard XML Schema Definition. JAXB adds more complexity to an application and requires more development effort. Its advantages are as follows:

Reads and writes standard file formats that applications written in any language can read, and in many languages generates classes to use the data similarly to how JAXB generates classes based on the file

Resulting serialized documents are human-readable and as friendly to edit as they are defined

Fast way to read XML data based on an XML schema — uses far less memory to represent an XML document in memory than a DOM tree

Its disadvantages are namely the following:

Requires more development effort — sometimes it is necessary to manage two data models: one your application can more efficiently use and the JAXB-generated data model

Working with JAXB objects can be unwieldy since they are generated — things like naming and object creation are more tedious to develop with than custom Java classes

278

Persisting Your Application Using Files

JAXB should be used when you want a human-readable file format that can be edited by users. It should be used when you are developing a file format you want non-Java-based applications to be able to read. It can be used in conjunction with other XML technologies, and to read third-party XML documents based on third-party XML schemas. It is a valuable tool that requires more development effort and more design, but its benefits far outweigh its costs — if you need a universal file format or just simply humanreadable XML.

Future Direction of JAXB 2.0

JAXB 2.0 will fix the one main problem with JAXB 1.0. It will allow developers to map existing Java classes to an XML schema. Essentially this solves the problem you had to deal with when you had to transform your JAXB-generated configuration data model to the Swing/UI-friendly one you custom developed. If JAXB had given you the ability to map your original book.Configuration data model to XML directly, there would have been no need to generate an additional data model and convert between the two. JAXB 2.0 will build on some of the new JDK 5.0 language features, such as annotations. Developers will have the ability to annotate their classes to define how they will be serialized to XML. This really is the best of both Java Serialization or XMLEncoder/Decoder and JAXB. Developers can design their data model in a way friendly to the Java environment, building their in-memory representations of the data, and then simply map it straight to human-readable and XML schema conforming XML. Once JAXB 2.0 is released, it will become probably the best way to serialize your classes out of the three technologies discussed in this chapter for most all design cases (though certainly not all). You can view the JAXB 2.0 specification online at the following URL:

http://www.jcp.org/aboutJava/communityprocess/edr/jsr222/

Summar y

Saving the state of an application to a file is saving all of the pieces of its in-memory data model necessary to reconstruct it exactly as it was at a later point of time. Most object-oriented applications store their data model as a set of data storage classes. In Java, it is standard practice to have the data model represented as a series of classes following the Java Beans conventions and utilizing collection classes where necessary (such as lists, maps, trees, sets, etc.). In applications that have graphical user interfaces, it is best to separate the in-memory data structure from the GUI toolkit classes as much as possible. The standard Java GUI toolkit, Swing, follows the Model-View-Controller design pattern to accomplish this separation. This way, to persist the state of an application, only the data model needs to be written to disk — the GUI is simply a transient aspect of the state of the application. Normally, when you say you want to be able to save an application’s state, you are referring to saving some sort of file that an application produces, whether an image file, a word processing document, or a spreadsheet. These types of files are simply a data model persisted to disk. By keeping your data model separate from your GUI classes, it is easier to save it off to a file. The Java Serialization API and the XMLEncoder/Decoder API have been looked at in this chapter. These APIs literally take a set of Java classes, and persist enough information to disk to reconstruct the actual object instances as they used to look in memory. This methodology makes adding serialization capabilities to an application very easy, but at the cost of limiting the use of the serialized information to Java-based applications.

279

Chapter 5

The JAXB API takes a fundamentally different approach, and first defines a common file format that can be read from any application using the W3C standard XML schema technology. From this schema, JAXB generates the in-memory data model for an application. It is essentially the reverse design process of the Java Serialization API and the XMLEncoder/Decoder API. Both the JAXB API and

the XMLEncoder/Decoder API persist their information in XML — but the XML produced by the XMLEncoder/Decoder API can only be used by Java-based applications. The Java Serialization API serializes its information in a Java-specific binary format that is much more efficient than XML, but again, is only useful by Java applications and is not human readable. Persisting your applications using files can require as little design and development time as you give it. If you use JAXB, it takes a little more time. Your application’s in-memory data model is probably the most important aspect of your data design. Once that exists, the various serialization and persistence strategies found in this chapter can all be applied. The next chapter talks about how to serialize your application’s data model using a database, which is usually necessary for multi-user systems.

280

Chapter 6

Persist changes to a data source

Retrieve information from a data source

Interact with legacy filesystems

The JDBC API is based on the specification X/Open SQL Call Level Interface (CLI), which provides an application with an alternative method for accessing databases with embedded SQL calls. This specification has been accepted by the International Organization for Standards (ISO) as an international standard. ODBC is also based on this standard, and the JDBC API can interface with ODBC through JDBC-ODBC bridge drivers.

The JDBC API makes it relatively simple to send SQL statements to databases, and it doesn’t matter what platform, what database vendor, or what combination of platform and vendor you choose to use. It’s all done through one common API layer for all platforms. This is what makes Java the front-runner of programming languages in today’s market. Although there are different vendors who are creating their own drivers, they all must follow the JDBC 3.0 specification. With that said, all drivers fit into four categories.

The first two driver-type options are usually temporary solutions to solve the problem, where the JDBC driver for the particular DBMS (Database Management System) in use does not exist. The third and fourth driver-type options represent the normal, preferred usage of JDBC because they keep the platformindependent fundamentals in place. If you would like to find out if your DBMS vendor supports a particular version of the JDBC API, please check out the following Web site for details: http://servlet. java.sun.com/products/jdbc/drivers.

282

Persisting Your Application Using Databases

The JDBC API is contained in two Java packages — java.sql and javax.sql. The first package, java.sql, contains the original core APIs for JDBC. The second package, javax.sql, contains optional, more advanced features such as row sets, connection pooling, and distributed transaction management. It is important to determine your application’s data access needs and architecture ahead of time to properly assess which packages you need to import.

Setting Up Your Environment

To use the JDBC API and its advanced features, it is recommended that you install the latest Java 2 SDK Standard Edition. The JDBC API is currently shipping with both Java 2 SDK SE and Java 2 SDK Enterprise Edition (the latter is a must if you are doing server-side development).

You will also need to install a JDBC driver that implements the JDBC 3.0 features. Your driver vendor may not support all the features that are in the javax.sql package, so you should check with them first.

Finally you will need access to a Database Management System that is supported by your driver. Further information on JDBC support can be found at http://java.sun.com/products/jdbc/.

JDBC API Usage in the Real World

The JDBC API is most commonly used by applications to access data in two main models: the two-tier model and three-tier model, both of which will be covered in the following paragraphs.

Understanding the Two-Tier Model

The two-tier model is the simplest of the models. It comprises a client layer and a server layer. The client layer interacts directly with the server layer, and no middleware is used. The business logic, application/ presentation layer, transaction management, and connection management are all handled by the client layer. The server layer contains only the data source and doesn’t manage anything that the client is doing, except for user access and rights. Figure 6-1 illustrates the two-tier model.

This is a good design for small applications but would present a scalability dilemma for larger applications requiring more robust connection and transaction management.

283

Chapter 6

CLIENT LAYER

Client

JDBC Driver

Data

Server

SERVER LAYER

Figure 6-1

Understanding the Three-Tier Model

The three-tier model is the most complex and the most scalable of the models. It removes the business logic and adds a layer of abstraction to the data sources. This model is shown in Figure 6-2.

The client layer in this model is a thin client layer that contains only very lightweight presentation layers that will run on Web browsers, Java Programs, PDAs, Tablet PCs, and so forth. It does not handle business logic, methods of accessing the data sources, the drivers used to provide access, or the methods in which data is saved.

The middle layer is where the core of the functionality exists in the three-tier model. The thin clients interact with applications that support the business logic and interactions with data sources. Connection pools, transaction management, and JDBC drivers can all be found here. This is the layer that adds increased performance and scalability compared to the two-tier model.

The data layer is where the data sources such as database management systems and files exist. The only interaction that occurs here is from the middle layer to the data layer through a JDBC driver.

The main benefit of the three-tier model is the fact that it adds layers of abstraction that can be scaled, removed, added, and improved upon. It also adds extra performance benefits when simultaneously accessing multiple data sources. The main drawback is that it can be expensive, depending on the choices made for the application server software and the hardware to run the system.

284

Persisting Your Application Using Databases

Client Layer

Thin Clients

Applications

App. Servers

Drivers

Middle Layer

Connection

Pools

Server

Transaction

Management

Grasping JDBC API Concepts

For this part of the chapter, you will explore the main usage of the JDBC API before moving on to more advanced topics, such as managing database meta data, utilizing RowSets, connection pooling, and managing transactions to insure that you have a solid foundation with which to start your JDBC API journey. This section will also act as a good review for those of you who need it, and it will cover the following topics:

Managing JDBC API connections using the DriverManager class and the new DataSource interface

Creating, defining, and understanding statements

Utilizing result sets to retrieve and manage database information

285