When Java was first publicly released in 1995, few could have expected the rapid growth of the language, as well as its pervasiveness throughout the computing industry. Within a few short years, Java has moved from the browser to applications, then to the Web server, and just recently, to palm-top computers. Java code powers a massive amount of systems and has gone from a promising language for applet and Web design to a powerful tool for building mission-critical systems.
If you’ve left it till now to consider Y2K problems, it’s still not too late to evaluate your Y2K risk!
Due to the change in focus of Java, the impact of Y2K must be seriously considered. While the failure of applets on Web pages is minor (as applets are automatically downloaded from Web servers and make distributing updated versions of software effortless), the same cannot be said for servlets or applications that have already been distributed and deployed. Furthermore, even perfectly written software has the potential to fail. This can be due to defects in the Java Virtual Machine (JVM) on which it is run, defects in the Sun Java API or third-party APIs, as well as JavaBean components and third-party systems that interact with Java software. Even development tools may be affected, which could disrupt development plans in the New Year.
The key to evaluating Y2K risk is to determine problem areas
If you’ve left it till now to consider Y2K problems, it’s still not too late to evaluate your Y2K risk! The key is to determine where the greatest potential for problem lies and to take immediate corrective action.
Let’s examine some of the most likely places to cause problems. The following diagram identifies four main areas where there are potential for Y2K problems. Please note that this includes only software risks — physical risks such as electrical supply or network failure are not included. If this happens, Java will be the least of your worries!
Figure 1. Four key areas for Y2K problems.
The first area of concern is your Java Virtual Machine, which runs the Java software you produce. Most people will tend to focus on the application itself, and fail to consider what happens when the application (and any Y2K updates) are deployed. If your Java Virtual Machine fails, so does your application. For this reason, your are strenuously urged to update your JVM at the earliest opportunity (do it now!), and to advise your clients to do the same. There are issues associated with older JVMs, and minor Y2K bugs in the core Java API. Sun provides details of these at their Y2K Product Compliance Status Table site (see Resources), and you should obtain the latest third party JVMs if you choose to rely on them. Replacing your JVM will solve some date-related problems with the Date.parse() method, SimpleDateFormat.parse(), SimpleTimeZone.offset() and the GregorianCalendar class. Ironically, these are related to leap years, so the problem is unlikely to hit on January 1, unless your application deals with advance dates such as a booking/scheduling application. However, February 29 will cause problems, and any application that deals with dates, has the potential to crash with an uncaught exception. You should also install any operating system updates which might prohibit your JVM from working correctly on January 1.
The Y2K bug may strike Java software, but with a little vigilance you can minimize your Y2K risk and prevent nasty surprises.
The next area of concern is the core Java APIs, and any extensions. As mentioned above, there are some issues with the java.util package, and date-related classes/methods. However, the problem doesn’t end there. You’ll be surprised to know that other areas may be affected. For example, the Java Servlet Development Kit (JSDK) 2.0 has Y2K issues with the last-modified header, and Sun advises obtaining an updated version of the jsdk.jar file. Early versions of the JavaMail API have date-related issues, according to Sun, but the latest version of JavaMail does not. Not only must the JVM be updated, but any standard extensions, third party APIs, and JavaBeans as well.
The third area of concern is actual application code. Here is where most Y2K defects will be located. Many developers take shortcuts, such as including two-digit fields in their data structures, or hard-wiring date code logic. For example, treating an 00 field in your data-structure as 1900 might cause application logic or calculations to fail, as it was not anticipated that such a date would be reached. If you do use such data-structures, you should take immediate action to convert between the existing structure and a new structure with larger fields. Developers should also consider object persistence, and the java.io.ObjectInputStream / java.io.ObjectOutputStream classes. These will correctly read and write a java.util.Date, if it is a instance variable of an object.
The final area is one that may be overlooked in the rush to patch systems. Interfaces to external systems have great potential for problems, particularly if those systems are independently controlled. If your Java system uses JDBC to talk to a database, and the database is not Y2K ready, then your Java application may find itself unable to access the database, or that the data returned is incorrect. CORBA clients talking to legacy C++, Ada, or Cobol code might get back inaccurate data, leading to system failure. Not only should you check to see that other external interfaces are ready, but your code should be ready to handle failures (such as 00 rather than 2000 returned as a year).
Other issues of concern
While keeping systems up and running, is of course, the primary concern, developers may also have to consider the failure of development tools. A development tool that fails the Y2K test won’t necessarily put it out of action, but could prove an unwanted annoyance in the New Year (particularly if you’re already rushing to complete late Y2K problems). The following table summaries Sun development tools which are listed as having Y2K issues, or that require patches.
Development Tools affected by Y2K
When updating the JVM of client machines, don’t forget to remember that the same problems can affect JDK, and the Java Plug-in. You should update these for all development machines, being careful not to miss any. Some date-related errors for Java will affect leap years, and not just January 1, so be sure to be thorough about this.
The Y2K bug may strike Java software, but with a little vigilance you can minimize your Y2K risk and prevent nasty surprises. The news is quite positive for developers, due in part to the relative newness of Java, and the thorough itemization of Y2K compliance by Sun. By installing the latest software updates to your Java Virtual Machine, to Java APIs and JavaBeans, external systems which a Java system may rely on, and finally your development tools, the only Y2K headache you may face is a New Year’s Eve hangover.
- Sun’s Year 2000 Product Compliance Status Table
Here you’ll find further information on Y2K compliance of Java APIs, Java Virtual Machines, and development tools.
About the author
David Reilly is a software engineer and freelance technical writer living in Australia. A Sun Certified Java 1.1 Programmer, his research interests includes the Java programming language, as well as networking & distributed systems. He can be reached via e-mail at firstname.lastname@example.org, or at his personal Web site.