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
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.