Java for the AS/400

We in the AS/400 Division are betting on Java to become our future business programming language for object-oriented applications, and we are putting a huge effort behind it. An early question we had was how to best implement the Java VM on the AS/400. We wanted to make sure that our implementation would leverage all the strengths of the AS/400. The answer was fairly obvious.

If my description of Java as a full software platform that simulates a computer in software sounds familiar, it should. The AS/400’s machine interface (MI) has similar characteristics. Look at the Advanced 36, for example. Built into the MI of every AS/400 RISC model is a full System/36 “virtual machine” that is capable of running the SSP operating system and all System/36 applications. Furthermore, the System/36 instruction set in the MI is emulated, meaning the instructions are interpreted. This is exactly the concept behind Java byte code.

The logical way for us to implement the Java byte codes on the AS/400 was to extend the definition of the MI. This approach is also similar to what we did to support the ILE program model, where we implemented W-code (the intermediate text of the ILE compilers) directly in the MI. We could then implement the Java VM (which is a byte-code interpreter necessary to run Java programs) in SLIC, just as we did for the System/36 code.

Interpreted Java may work fine on most client applications, but it is not likely to provide competitive performance for many server-based applications. For this reason, we decided to incorporate a full compiler as well as an interpreter into the AS/400 Java runtime environment.

One of the keys to good Java performance on the AS/400 is native threads. I introduced native threads for the AS/400 in Chapter 9. Although traditional AS/400 applications are not written to a threads model, applications for other operating systems generally are. Both Unix and NT support threads models, so we should expect that cross-platform Java applications almost certainly will be written to a threads model. Good threads performance is critical for the AS/400 to play in this cross-platform game. Native threads gives us that performance.

In Figure 9.7, I showed how the various application enablers — such as the runtime libraries for C, C++, and Java; the IFS; and the class libraries for objects — relate to the native threads implementation. It should be clear that native threads benefits not only Java applications but also any ported applications that were originally written for either Unix or NT operating systems. For example, native Domino on the AS/400 is a port of Domino for AIX. Thus, Domino for AS/400 is also dependent on good threads performance.

Although Java and the Java object model represent the best hope for cross-platform applications, the AS/400 continues to support IBM’s System Object Model (SOM). Unlike Java’s object model, SOM is defined to be language independent. SOM objects are defined using an Interface Definition Language (IDL) and can be used by OO and non-OO languages alike. SOM is based on the standard created by the Object Management Group (OMG) known as the Common Object Request Broker Architecture (CORBA). The idea behind this effort by OMG was to create an open, cross-platform object model that can be used with multiple languages and operating systems. The latest version of this standard is CORBA-2, which enables legacy applications written in C++ and Smalltalk to communicate with Java and also to be more easily ported to Java.

In the vendors’ efforts to establish an industry-standard object model, Java and Microsoft’s COM are leading, with OMG CORBA-2 a distant third. The future of the OMG CORBA standard is uncertain. Even though we are making the bulk of our AS/400 investments on Java, we have been able to use much of our earlier work on SOM for our Java implementation.

With V3R6, we introduced SOMobjects for the RISC models. SOMobjects provides the runtime support for SOM in the AS/400. SOMobjects allows portability of classes across the various systems that support SOM. SOM-objects also includes a variety of frameworks. Object reuse is possible through the use of class libraries, as we saw in Chapter 3 when we looked at OO concepts. Another similar approach to sharing objects is through the use of frameworks. A framework is a collection of objects to provide a common solution to a particular problem. A class library is more general purpose, not necessarily designed for a particular problem.

A very important framework included in SOMobjects is the Distributed System Object Model (DSOM) framework, which you can use to write applications based on distributed objects. The DSOM framework allows a program in one system to execute a method on an object in a remote system. When a program creates an instance of an object, that object can be on a remote system. The DSOM framework recognizes the object is remote and starts a conversation with the DSOM framework at the remote site. The remote-site DSOM framework creates the actual instance of the object, while the local DSOM framework creates a shadow of the object, called a proxy. The program talks to the proxy, and the local DSOM framework takes care of routing requests to the real object at the remote site. This process is transparent to the users.

The implementation of SOM on the AS/400 goes one step further than the implementations in other systems and supports the idea of persistence. We discussed persistence in Chapter 8 when we looked at the single-level store. In other systems, the lifetime of objects corresponds to the duration of the job that created them. This limitation causes problems if you want to share objects across different jobs. Other systems have implemented various solutions; for example, there is a Persistence framework in OS/2 and AIX. These solutions still require the programmer to manage the object persistence by ensuring that the object contents are periodically made permanent on disk, which can require a significant programming effort. The AS/400 doesn’t use the Persistence framework.