In his blog, Rob did a good job of explaining the benefits of writing Java in an Oracle database. In the case study he mentions, the use of Java code was absolutely necessary. Without using Java, the code ran so slowly that it could not have been used in production. By rewriting large parts in Java, the developed product was able to be effectively used by the client. It is clear that having Java run in the database in a JVM (Java Virtual Machine) is a valuable feature of the Oracle database. Java has a place in the Oracle developer toolbox right next to PL/SQL.

But the same case study that Rob mentioned also exposes one of the weaknesses of running Java code in the database. After a period of use in production, users discovered that under certain circumstances the developed solution would generate an error message and the code would cease to function. After investigation, we determined that the problem was not with the code that was written, but instead was with the Java Virtual Machine installed in the database.

Java is designed to be a language that can be written once and executed on any platform that has a JVM installed. The JVM provides a consistent environment for the code to run regardless of what platform the JVM is installed. For example, Java code running inside a JVM on a Windows platform will theoretically run the same as Java code running inside a JVM on a Linux platform - as long as the Java code was written to be compatible with the version of JVM installed on both platforms.

The same principle works with the Oracle database JVM. The Oracle database JVM can execute code just as a Windows platform JVM does. In our case study, we discovered a problem with the Oracle JVM. The resolution to the problem was obvious. We needed to have an updated JVM installed in the database.

With JVM environments outside of a database, this is fairly routine. Sun (and others) produce JVM versions on a regular basis. Installing the JVM is as easy as installing any other software on the system. And because multiple versions of the JVM can be installed on the same machine, installing an updated JVM will not necessarily affect other Java applications.

The same cannot be said about the Oracle JVM. The Oracle JVM cannot be updated independent of the database being upgraded. Oracle produces the JVM that the database uses. In fact, the way to update the Oracle JVM is to upgrade or patch the database as a whole. In a regulated environment, this is not as easy a task as upgrading a JVM that exists outside of a database. In addition, because of validation effort and because many vendors develop applications dependent on specific versions of Oracle, some pharmaceutical companies are bound by which version of the database they can run. Upgrading the database may not be an option, which means that updating the JVM may not be an option. It is possible to be stuck with an older version of the JVM.

This situation isn't really that different from the situation with other proprietary database languages. They do not get updated either unless the database gets a new revision. The difference with Java is that Java is designed to be platform independent and to have the JVM be easily upgraded. That is not always the case when running Java in an Oracle database.

Java is still a good option for certain computational tasks running in the database, but the reality is that it is not always as easy as taking external java code and running it effectively in the Oracle database. Because of the way that the Oracle database environment is set, developers may be using outdated JVM environments for development.