The magic of Merlin

How the new JDK 1.4 -- code-named Merlin -- levitates its functionality

Sun Microsystems has promised a 12- to 18-month time frame for each major release of the JDK. To keep within that time frame, Sun hopes to unveil the beta release of the JDK 1.4 -- code-named Merlin -- this March. The Java Community Process (JCP) has been working on the release for more than a year. The coolest thing about this release is that the JCP allows its users to actively participate in deciding the features and the direction that Java should take. Merlin was developed under Java Specification Request (JSR) 59.

According to Merlin's JSR, the release is focused on reliability, serviceability, scalability, performance, and deployment. I define it as a focus on building "maintainable software." It will include many new APIs with added functionality, for which we had to use third-party APIs in the past. Getting those APIs bundled with JDK will standardize them; that will reduce software development time and maintenance costs. I will talk about those APIs shortly. Merlin's final feature set is not yet public, so some of the features discussed in this article might not appear in the final release.

I've used various JSRs on the JCP Website as resources for this article. If you're already familiar with these JSRs -- such as JSR 59 Merlin release contents, JSR 54 JDBC 3.0 Specification, and JSR 31 XML Data Binding Specification -- you already have a head start. Otherwise, I strongly recommend that you check out the JCP Website. JSRs not only tell you what is coming in a new release (thus giving you a market advantage), but also allow you to participate in the Java development. (See Resources for more information.)


XML is already an essential part of Java and the Web. Java and XML will likely be more closely connected in the future, as XML complements Java nicely. XML parsers with DOM and SAX APIs are already available on Sun's Website. (See Resources.) Version 2.0 of those parsers is under development and will be bundled with Merlin.

JDOM API, another XML parsing API, is also under development under JSR-102. There are no plans to bundle JDOM with Merlin. A new specification called XML Data Binding is under development and will be shipped with Merlin. XML Data Binding is a higher level API than DOM, SAX or JDOM; it is a combination of powerful document definition and corresponding XML parsing and data validation.

As of today, document type definition (DTD) is a widely used mechanism for XML validation. DTD has a few limitations; for example, you cannot specify that a string can only be 10 to 13 characters long. DTD was a quick fix to a nonexistent validation mechanism. Now with experience and time, the World Wide Web Consortium (W3C) has come up with a new recommendation called XML Schema. It is a more elaborate and flexible mechanism to validate an XML document. Technically, you can write a set of classes that represent the XML Schema. Those classes can parse, load, and validate the XML document and create Java objects for nodes, which you can use directly in your Java programs. XML Data Binding is just a mechanism to generate those classes automatically for any given XML Schema. With XML Data Binding, all the code that was required to parse the XML and extract the meaningful objects will not be required. Sun's work on XML Data Binding is also known as Project Adelard. (See Todd Sundsted's "Adelard, One Year Later" (JavaOne Today, June 2000).)

Logging API

Companies are becoming more aware that fixing a software defect during deployment can be up to 100 times as costly as fixing it during development. Hence, is it not only important to build the software the right way, but also to provide hooks and tools to trace problems in released software. Logging is an important part of building maintainable software. Today, many logging APIs exist, but they are not standardized, and few developers make the effort to evaluate and use them. Some developers tend to write their own logging APIs, which generally are buggy, nonoptimized, and nonextensible. Merlin solves those problems by including a built-in logging API.

The new logging API offers no surprises. It is based on well-known concepts of priorities, filters, formatters, and handlers. You call the logging module with the message and a priority (like "WARNING" or "SEVERE") for the message. The message passes through filters that decide (based on configuration) if the given priority message should be logged or discarded. The formatter formats the message string -- it adds time stamp, thread stamp, exception stack trace, and so on (again based on current configuration). The handlers are responsible for writing the log message to the output device -- such as a file, socket, or database. You can create your own filters, formatters, and handlers and plug them into the framework. The API provides a complete set of functionalities required for most projects. If needed, you can build more complicated mechanisms on top of this framework.

JDBC 3.0

JDBC 1.0 -- introduced with JDK 1.1 -- had minimal database functionality. JDK 1.2 delivered JDBC 2.0, which contained enhanced features like scrollable result sets, batch updates, BLOB and CLOB support, ARRAY type, user defined types (UDTs), structured types, and distinct types. Then came the development of the JDBC 2.0 optional package: a standard extension that provides the DataSource class (which uses JNDI to connect to any kind of data, such as flat files or spreadsheets), connection pooling, distributed transactions, and RowSets (a higher-level interface on top of ResultSet).

For its part, Merlin has major JDBC changes in store. It is being bundled with JDBC 3.0, whose complete feature set would take another article to describe. If you want more detailed information than this article provides, see Resources.

JDBC 3.0 contains the JDBC 2.0 classes and the JDBC optional package classes. That means the optional package is being merged into standard JDBC, making the Java platform more flexible and complete. The SQL99 standard has also been finalized, so JDBC 3.0 will also attempt to be consistent with that standard. JDBC 3.0 will not support the whole SQL99, but the features that are implemented will be consistent with the standard.

A mechanism for connecting JDBC with a connector architecture using the Service Provider Interface (SPI) is also in the works. The connector architecture is a general way to connect to enterprise information systems (EIS), such as ERP systems, mainframe transaction processing systems, and hierarchical databases. The connector architecture specification defines a set of contracts that allow a resource adapter to extend a container in a pluggable way.

Three new row sets have been implemented. JDBCRowSet makes the JDBC driver look like a JavaBean component. You can use it to make JDBC applications with GUI tools. CachedRowSet loads the data into a cache and disconnects the SQL connection from the database. Hence, you can pass that cached row set between tiers of the application. It also helps to optimize the database connections. Any changes made to the cached data can later be reflected back into the database. WebRowSet lets you convert JDBC data (with its properties and metadata) to XML, which you can use anywhere. You can also convert the XML back to data and save any data changes back to the database. This will be very useful with upcoming XML communication protocols and tools. You can also use custom readers and writers with these row sets to provide your own mechanisms to read and write data. For instance, you can provide custom mechanisms to read data from a nonrelational database or you can provide your own conflict-resolution mechanism while saving data.

Other features of JDBC 3.0 include:

  • Savepoint support (the ability to roll back transactions to designated savepoints)
  • Connection pool configurations (added properties to describe how PooledConnection objects should be pooled)
  • Reuse of prepared statements with connection pools (in JDK 1.3, when you close a SQL connection, the prepared statement dies with it, but now the statement will be independent)
  • Retrieval of parameter metadata (the new interface ParameterMetaData describes the number, type, and properties of parameters to prepared statements)
  • Retrieval of auto-generated key columns
  • Multiple open result sets on a statement
  • BOOLEAN data type
  • DATALINK data type (allows JDBC drivers to store and retrieve references to external data)
  • Updateable BLOB, CLOB, ARRAY, and Ref objects
  • Transform groups and type mapping (defines how UDT can be transformed to a predefined SQL type and how that is reflected in metadata)
  • DatabaseMetaData APIs that retrieve SQL type hierarchies


Also bundled in the new release is the optional Java Secure Socket Extension (JSSE) package. JSSE implements Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols. It is currently available for download as an extension. (See Resources.)

Java Authentication and Authorization Service (JAAS) is a new API that lets you establish access control on a per-user basis. JAAS is incredibly useful; for example, you can use it in situations when an administrator needs more menus and options than a normal user.

Java Cryptography Extension (JCE) is another standard extension that will be bundled with Merlin. JCE provides functionality for encryption, key generation and key agreement, and message authentication code (MAC). Fortunately, JCE can now be exported from the US and Canada because of more lenient security regulations. Now, applications that use cryptography can be exported, so people in other countries can benefit from the Cryptography API. That means only the policy files that define the cryptographic strength are altered; then the application can be exported to international customers. Public Key Cryptography Standards (PKCS) support is also being finalized.

A reference implementation for the Certification Path Building and Verification API is already under way. This will allow access to certificates (and hence, public keys) via LDAP/JNDI. This benefits applications that need to deal with SSL, signed code, S/MIME, and so forth.

Preferences API

Most applications need to store preferences and configurations. Those settings are generally stored in properties files that are not very elegant to work with. Sometimes, if the user base is very large, user preferences are also stored in an LDAP/RDBMS. These mechanisms are also not totally reliable; for example, if you store configurations in a properties file, where do you keep that properties file? Similarly, if you store them in an LDAP/RDBMS, where do you keep the connection parameters for the LDAP/RDBMS?

Hence, a new preferences API was developed; it will provide a mechanism to store application-wide configuration as well as per-user settings. Not many details about this API are available -- we will have to wait and see.


Java code will be easier to debug, thanks to upcoming assertions. Assertions were supposed to be included at the time of JDK 1.0, but were dropped due to time constraints. Using assertions, you can provide various checkpoints in the application to validate data or the application's state. If an assertion fails, an AssertionError is thrown. A new keyword called assert will be added to the Java language. Assertions are generally used for developing software; hence, Merlin provides hooks so you can disable the assertions when your software is put into production. This will cause minimal or no overhead on the software's deployed version. You can enable or disable assertions dynamically by calling a method on ClassLoader. You can also change the assertion status on a per-package, or even per-class, basis. Assertions are meant to be a development tool and can be disabled, so you should keep in mind that assertions should not change the state of the system; for example, calling counter++ in an assert statement is a poor coding practice.


You will also find custom remote reference support in the RMI protocol. This will let you implement your own remote objects; for example, you can write your own remote object (like UnicastRemoteObject or Activatable) and use it over the standard RMI protocol. Since you'll define how the objects communicate, you can provide your own communication mechanism, like non-TCP-based communication or some custom secure communication.

RMI will allow more control of the codebase annotation so that multiple services running within a single VM can have separate codebases.

Security enhancements in RMI will allow a client and server to mutually authenticate each other. This adds security to the architecture and allows the server to execute code on behalf of the client (with the client's security).


CORBA enhancements include a portable object adapter (POA), which will allow transparent plug-in of any vendor's ORB implementation. It will also support server activation and object persistency. Portable interceptor APIs are also being developed, which will allow custom code to plug into the ORB. Portable interceptors will make it possible to run the J2EE Reference Implementation with any vendor's ORB.

1 2 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more