Java is hot! Or is it? If you ask a technical person, Java is most decidedly hot! If you ask a business person—such as the controller at your company—Java may look like yet another soon-to-be-unfulfilled promise of nirvana in the information technology (IT) department. Businesspeople have a well-earned skepticism about any new IT panacea, and, right now, they could be forgiven for mistaking Java for the latest one.

Businesspeople evaluate trends like the Java phenomenon in monetary terms. If it proves itself a money maker over some reasonable business period, then it’s probably a good thing. If it doesn’t, and it isn’t mandated by some external controlling body like the government, then business logic says don’t do it, no matter how technologically exciting it is.

When you look at the reasons companies cite today for moving to Java as a primary software technology, most of them appear at first glance to have a propeller-head bias. Reasons often cited for using Java today are cross-platform compatibility, programmer’s interest in Java, and an open computing environment.

Hmmm, OK, I’m a businessperson, and I’m supposed to go to Java because it runs on a lot of computers and my programmers like it. Please! In my business, we don’t let the dump truck drivers pick the trucks, and we don’t let the programmers pick the IS infrastructure technology.

There are solid business reasons for using Java and for using AS/400e as your primary Java server, but most analyses of Java to date have focused on the gee-whiz technological aspects of Java. These reasons won’t cut it when Dr. No gets hold of your pet Java project (every successful company has a financial officer with the responsibility of saying “no” to fanciful, but unjustified, projects).

In AS/400e shops, the business case for Java rests on the twin pillars of Java capabilities and the inherent strengths of AS/400e as a Java server. Java provides a never- before-seen ability to change the way businesses create and use software. This ability derives from the combination of Java’s universal deployability, object-oriented (OO) characteristics, accessibility (here, I use the word accessibility to mean that programmers

can get at, understand, and use its capabilities), and TCP/IP support (i.e., World Wide Web) computing. OO software can be deployed in an iterative, piecemeal fashion that closely matches the way that people develop and use business processes. OO software development and deployment can be more responsive and less affected by change than other software technologies. When you combine OO capabilities with AS/400e Java servers and systems, you have an integrated, reliable, manageable business process software infrastructure that can yieldreal-dollar benefits for your company by supporting software reuse, establishing an incremental software development and deployment capability, enabling an any-to-any strategy for access to enterprise IT resources, and permitting skill-set reductions.

So let’s examine those twin pillars (Java’s capabilities and the strengths of AS/400e as a Java server) in detail.

Write Once, Run Anywhere

Write-once-run-anywhere code is a reality with Java. If it weren’t possible, Java usage on the Internet would be nonexistent. Sure, it’s possible to write Java code that will run on only one platform, and sometimes it makes sense to do so. It’s also possible to optimize Java for performance, but, most of the time, it makes business sense to write Java code that is optimized for portability. The key words here are “100% Pure Java” and “Java Compatible” (terms that Sun Microsystems coined). 100% Pure Java means using the Java language itself to accomplish the task at hand, rather than going around or outside the language to use an external component or add-in. Java Compatible is the other side of the portability coin. To be certified as Java Compatible, a system must pass an exhaustive suite of tests that ensures it will correctly run 100% Pure Java programs.

Most businesspeople understand the value inherent in write-once-run-anywhere code: The benefits of portable code and skill-set reduction result in lower-cost, more- effective software development and deployment. What those businesspeople aren’t sure about is the claim’s credibility. And this insecurity has been exploited by companies that want Java to succeed as a language but not as a cross-platform software deployment technology. However, experienced Java programmers know that write-once-run-anywhere code is real and that it is an achievable coding practice. I have written Java code on OS/2 and then run it on OS/2, Windows 95, and AS/400e. I have also assisted in porting large Java programs (low six-figure lines of code) from Windows NT and UNIX to AS/400e. Porting meant copying the program to the AS/400e and seeing if it ran.

It did. Write-once-run-anywhere is a real business advantage for Java. IBM’s San Francisco Project is another example of meaningful cross-platform Java deployment. San Francisco is a set of cross-platform business objects written in Java. These objects constitute the core functionality of business applications like general ledger, accounts receivable, accounts payable, order management, and warehousing. Together, these objects make up a large (hundreds of thousands of lines of code) line-of-business application that runs on OS/2, Windows 95, Windows NT, AIX, Sun, AS/400e, and several other platforms. Write-once-run-anywhere code works.

The value of portable, write-once-run-anywhere code is skill-set reduction. If your programmers can work in only one language, then they can concentrate their energies on the most effective use of that language. And you can reduce the number of software development tools that you buy and support. When I switch from one language to another, even to a language that I know well, a certain amount of paradigm shifting occurs. Paradigm shifting does not contribute to programmer productivity.

Productivity

Productivity is often cited as a strength of Java. I was skeptical when I first heard this theory, as all new languages claim productivity as a benefit.

Java productivity comes in three forms: language-inherent productivity gains, tool- based productivity gains, and OO reuse of code. Java is more productive than some languages for some tasks and less productive than other languages for other tasks, so it’s pretty much the same as any other language. For Web development, it is the winner hands down. No other language even comes close. C++ programmers consider Java a major productivity improvement, because it requires less (as in none is less than some) management of machine-oriented details like memory, pointers, and the operating system. Programmers coming to Java from other non-OO languages find mixed results. However, within six months to a year, as these OO neophytes become more proficient in Java, they too begin to see productivity improvements.

Tool-based productivity gains appear to be real. Java is the most recent language introduced in our industry. Being the newest means having the newest, most evolved development tools. My experience with IBM’s VisualAge for Java indicates that the productivity gains are quite large. With VA Java, I have produced code at a rate of better than 30,000 lines per day. While that isn’t sustainable, large quantities of code can be cranked using a visual development tool. And the code is high quality.

OO code reuse is a very important business benefit, and Java is an OO software development tool with a well-documented, pragmatic set of standards for writing reusable code. Good OO strategy involves developing software components that combine with other components to produce an application. These software components can work at many different levels within the hierarchy of component combinations. A software component can be a fundamental component (like a brick in a house), or it can be a component that is a combination of many fundamental components (just as a stove in a house combines a metal structure, heating elements, and control switches). Once a component is developed, tested, and given the ability to tell other systems about itself, it can be widely reused just as a standard brick can be used interchangeably in structures of many different houses. Just as the original brick specification is implemented as many individual bricks, so the Java component (a.k.a. JavaBean) is implemented as individual objects based on the original component specification. The business productivity gain is real. A little care in design today means that the component that you write today can be reused well into the future. And you don’t have to rewrite the function-ality represented by the component again and again as we have come to expect with legacy applications (or even a poorly designed OO application for that matter).

Leverage the Web

Java is the language for Web development. It was designed to include TCP/IP network support like Sockets, URLs, and the other IP network functionality necessary to develop network-centric software. You can extend the reach of your existing enterprise software, data, and computing resources to the Web via Java without redoing the existing resource base. An existing program can be front-ended with a Java applet to make it available to anyone you choose anywhere in the world. While some may decry this as “screen-scraping,” it makes excellent business sense. Your existing programs are a large investment of time and dollars. Increasing their value by extending the reach and utilization of those programs is a smart move and an effective use of technology. Java can do the same for your enterprise data and computing resources. Java applets can help you provide your authorized users with access to your enterprise databases and server resources from anywhere.

In fact, this access by any authorized user to any (authorized) content on any (authorized) server is one of the main reasons that the Web has been so successful. Instead of providing predefined mechanisms—and especially predefined paths—for access to information technology resources, authorized users are permitted access to any IT resource that helps to accomplish their jobs. Java, as the software development component of the Web, is an important part of an “any to any” information delivery strategy. Of course, it’s important to ensure that only authorized users are allowed access. Java was designed with security in mind and provides the necessary tools to ensure that your business knowledge base can be delivered safely over the Web.

An important part of “any to any” access is server-side computing. Server-side computing takes advantage of your expensive servers by using them for computationally intensive tasks like searching large databases, building complex knowledge bases, or making large-scale changes to enterprise data (e.g., all prices just went up by 3.5 percent). Business rule layer content is generally placed on the server as well. Business rule content is the expression in software of how you run your business. For example, if your policy is to provide a 2 percent discount for receivables paid within 10 days, then your receivables software must implement logic that supports this policy. This implementation of your business policy is contained in the business rule layer of your software. Java’s client/server programming capabilities and fundamental OO nature support the realization of your business policies into client and server software components that match your business model.

Portability is a major issue for servers, too. Very few shops of any size have only one (or only one type) server. Most shops today have multiple servers of multiple types
(e.g., AS/400e, NT Server, UNIX, etc.). The ability to run server-side code on any of those servers is an important aspect of write-once-run-anywhere code and skill-set reduction. The heterogeneous server farm is a reality today for business. Java is an important step toward using those varied servers more effectively and returning greater business value from expensive capital assets.I believe that server-side Java will eventually dwarf client-side Java in terms of value delivered to business. There will probably always be more client Java programs on a unit-count basis, but on a dollar-value-delivered-to-business basis, server- side Java will be much larger and more important.

AS/400e and Java

The business case for Java on AS/400e is built on the Java capabilities I’ve discussed combined with the AS/400e business case for Java. The AS/400e business case for Java depends on the details and the excellence of the implementation of Java technology, using a combination of AS/400e hardware and OS/400 and integrating these two components with Java to provide a complete Java server. Let’s examine these factors.

AS/400e has true 64-bit computing. Bits are like dollars; you may or may not benefit from having more of them, but everybody wants more. Having more bits in a process means a larger addressable memory space, wider data paths, and the potential ability to execute more instructions per clock cycle. That all adds up to more-powerful computing. So, if the engineers at IBM have been clever (and they have) in exploiting 64- bit processor technology, AS/400e has a potential advantage over most servers available today. The memory space issue is especially important to Java, as Java programs run in a large memory space. AS/400e also has up to 12-way symmetric multiprocessing (SMP) support. So an AS/400e can grow (or scale) to support very large business computing problems with Java. AS/400s also have many dedicated auxiliary processors to handle tasks like the network interface or disk I/O. This means that Java server programs running on AS/400e are less affected by low-level hardware tasks. AS/400e has many other

hardware technology advantages, but a dispassionate analysis yields that AS/400e is a good hardware platform for Java.

OS/400 is very interesting in how it matches up with and supports Java. First, OS/400 is an object-based operating system. Everything in the system is an object and can be accessed only by externally described mechanisms (methods in OO-speak) and attributes. One of the more important mechanisms is a security mechanism that can distinguish user objects from system objects and can prevent user objects from accessing or modifying unauthorized areas of the system. AS/400e security is a clear advantage for implementing Java on an AS/400e. OS/400 provides a facility called system-managed storage. Programmers and data analysts can concentrate on the business rule layer content and spend less time on low-level storage management issues. AS/400e system-managed storage complements Java’s information storage paradigms, which hide the underlying physical structure of the information from the programmer by representing it as objects. And OS/400 runs Java programs below the Technology Independent Machine Interface (TIMI). Programs running below the TIMI perform better, are more scalable, and are more resistant to being hacked.

AS/400e integration is an important part of the AS/400e business case for Java. IBM combines the hardware and operating system to yield a very reliable server. Designing and testing an AS/400e as a complete unit means that hardware and software can be optimized for each other. The AS/400e has an uptime percentage of better than 99 percent. Less downtime means less expense for your business. That’s one important reason that AS/400e-based information systems have the lowest life-cycle cost of computing for client/server systems (Source: Server Life Cycle Ownership Costs: Support Costs Relationship to Operating Environment Integration IDC, August 1997, Framingham, MA 508/872-8200).

AS/400e Java Technology

Now for AS/400e Java technology. AS/400e Java technology includes the Java Virtual Machine with Java Transformer, a Java Development Kit (JDK), the AS/400e Toolbox for Java, VisualAge for Java for AS/400e, and the San Francisco Project. Borland’s JBuilder Java development tool also supports the AS/400e by integrating the AS/400e Toolbox for Java into it.

The AS/400e Java Virtual Machine (JVM) is a 64-bit Java Compatible JVM. It runs under the TIMI, includes a dynamic Java Transformer, and has advanced garbage collection. I’ve already discussed the benefits of 64-bit technology and running under the TIMI, so let’s look at the Java Transformer and advanced garbage collection. The Java Transformer converts your Java programs at load time into 64-bit machine instructions to take advantage of AS/400e large memory spaces and processor capabilities. In short, it makes your Java programs run faster. There is no loss of portability, as the byte code is still 100% Pure Java. Java programs just run faster on AS/400e.

Advanced garbage collection is a key scalability issue for large Java programs. Sun Microsystems has done research that indicates Java programs spend 20 percent of their program runtime on garbage collection (For more information, see the article at http://www.javaworld.com/javaworld/jw-03-1998/jw-03-hotspot.html). In Java, garbage collection is the disposal of unused objects.

It’s done automatically in Java, like I wish it was done at my house. Most JVMs use “stop and copy” garbage collection. Again, this is just like at my house. When I’m taking out the garbage, I’m not doing something productive, like watching football. AS/400e has an advanced garbage collector, which does not stop the running program to do garbage collection. Again, Java programs run faster on AS/400e.

The AS/400e JDK is the AS/400e version of Sun Microsystems’ JDK. The AS/400e JDK includes the static Java Transformer. The static Java Transformer will let you convert, ahead of runtime, your Java programs into optimized 64-bit AS/400e executable objects. These optimized, compiled, 64-bit programs run faster because the conversion to machine instructions is done ahead of time, and AS/400e can optimize the code. There is no loss of portability, because the 100% Pure Java program still exists and is completely portable. Your Java programs just load and run faster on AS/400e.

AS/400e Toolbox for Java is a set of software components for accessing AS/400e resources. These components provide access for Java-capable client computers to get to the AS/400e database, print files, data areas, programs, and other resources on the AS/400e. Remember that a client is any computer that accesses another computer’s resources. So, a client using the AS/400e Toolbox for Java could actually be another server or a traditional client. These software components provide access to AS/400e for client/server or network- centric computing. Using these components to provide access to AS/400e improves programmer productivity and enables faster delivery of AS/400e resources to any authorized user on any Java-capable client that can manage an IP connection to the AS/400.

VisualAge for Java for AS/400e is an award-winning, highly productive development tool that can be used to develop Java programs that run on AS/400e or that run on clients to access AS/400e resources. It is tightly integrated with AS/400e, offering cooperative debugging and “smart-guides” for interacting with AS/400e resources. San Francisco is a large collection of business-process Java objects that provide business rule layer functionality.

Java Makes Good Business Sense

So, what does all the above add up to? The business cases for Java and AS/400e complement each other. Java offers write-once-run-anywhere software technology, the most usable OO software technology yet delivered to the commercial marketplace, and dramatic gains in programmer productivity. AS/400e offers a powerful, scalable, integrated system that provides better support for large Java server-side programs, enables the “any to any” computing model with broad and deep client support, and provides the most reliable server on the market today. All in all, Java is pretty compelling to both CIOs and AS/400 programmers.