Logo: TUG TORONTO USERS GROUP for Midrange Systems
TUG
e -server magazine

November 1997: Volume 13, Number 2


 coffee cup

Java Review for the RPG Programmer

By George Farr and Phil Coulthard

The Java Juggernaut

f you have read lately any computer magazine, or attended a conference, you may have noticed that Java is the dominant topic de-jour in all of these. Everybody is talking about Java. In fact, we have been asked by our neighbors, our friends, and even airport customs agents, "What is this Java thing anyway?" Not only our neighbors are wondering what Java is; the whole world wants to know. We hear of Java in the news, on the television, and in non-computer industry magazines. The hype machine is in full gear! The good news is, much of the hype is true, and over time all of it may be.

So, does this hot new Java technology affect you as an RPG programmer on the AS/400? Have your neighbors asked you about it yet? If not, they will. And so will your boss, to be sure. You too will have to at least look into Java. Why? Because Java is a programming language, as RPG is. Because Java is available now on the AS/400. Because Java is available now on about every computer platform that exists, including the new Network Stations. Because Java can be used now to write server Java applications, client GUI (Graphical User Interface) applications or web-page based applets that live and run in web browsers like Netscape. Because Java offers some significant business advantages such as portability, code reuse, buy and use componentry, compelling user interfaces, improved product reach through internets and intranets, and more. Because the computer industry is betting heavily, and investing heavily, in Java. Because IBM is betting heavily, and investing heavily, in Java. Because the AS/400 is betting heavily, and investing heavily, in Java. Because, it is good for your career, and your resume, to know Java!  Figure 1: RPG vs. JAVA

Fine, you say, so how do I start? You start by reading a book, or attending a conference, of course! You have already started by reading this article - good for you. Let us help you by introducing Java, the language. Java is an object oriented language. Sorry, but its good for you! If you are concerned about learning OO, it is probably because you have looked at C++ in the past. C++ is a great OO language, and the only OO language option on the AS/400, prior to Java. But C++ is a very difficult language to learn, and takes years to master. Java is, fundamentally, a simpler, kinder, C++. It is C++ for the rest of us, really. It is based heavily on the C++ syntax, but many of the complexities have been removed, such as pointers, memory management, multiple inheritance, include files and even those complicated "make" files. The biggest plus from a quality and productivity gain is the elimination of pointers and memory management. Java does its own memory allocation for you, and constantly runs a "garbage collector" in the background sweeping up automatically any unused memory. No memory leaks, no memory errors, no security risks pointers can pose. Furthermore, while C++ is really just C with OO capabilities tacked on, Java is a pure OO language. You don't effectively have to learn two languages this way, and you are not tempted to "drop down" to procedural non-OO programming practices. Object oriented programming really is a major improvement over procedural programming, and once you've "got it" you'll love it! Java then is the right language at the right time. It's an OO language without the C++ baggage. Java allows programmers to invest in an OO language that's easier to learn, easier to use. Further, that investment is well founded for the future due to the ubiquity of Java, and the major momentum behind it.

The Java Scene

Java is all about "write once, run anywhere". What does this mean, really? It means, having written one Java program, you can run that Java program just about anywhere. Anywhere, that is, that has a Java Virtual Machine (JVM). Java is an interpreted language (although compilers are starting to emerge, including one coming for the AS/400), and the JVM is the interpreter. Languages such as RPG, Cobol, or C have compilers that generate machine language instructions as a result of the compilation process that targets a specific platform. For example, as the following figure illustrates, the CRTBNDRPG and CRTPGM commands produce a program object (*PGM) that can only run on the AS/400.

In the case of compilers on the workstation, they generate machine code that run specifically on the PC. On the other hand, Java introduces a new way of compiling source code. Instead of having the Java compiler generate machine specific code that can only run on the target operating system, it generates an intermediate language, called Bytecode, that is simply more efficient to interpret than the source code. This bytecode is read and interpreted by the JVM interpreter which is shipped with the Java Development Kit or JDK. The javac command is this compiler (poor term). It takes in a Java source file (name ends with .java), and spits out a Java bytecode "class" file (name ends with .class). The JDK also includes the JVM and a number of "packages" of useful classes for your use. To "run" a Java application you "run" the JAVA command and specify the class file name as a parameter. The JAVA JVM reads and runs that class file, which probably in turn refers to other class files, which are subsequently loaded and run by the JVM automatically, as needed.  Figure 2: RPG vs. JAVA

The company JavaSoft produces the JDK for Solaris and Windows, and companies like IBM license and port it to their operating systems. You can get, via free web download, the windows JDK from http://www.javasoft.com, and the AS/400 "preview" JDK from http://ncc.hursley.ibm.com/javainfo. Another piece you will need, for AS/400 data and program access, is the AS/400 Toolbox for Java, a set of AS/400 unique Java classes (that is, "packages" of classes). This hails from IBM Rochester and is downloadable by following the links for Software, and then Java, from www.as400.ibm.com. These classes can be run in client Java applications or applets that access the AS/400, or on the AS/400 itself in server Java applications. To create and edit your Java source, you can use any PC editor, even WinEdit. The CODE/400 editor on Windows (www.software.ibm.com/ad/varpg), if you already have it for RPG or Cobol, is also a good choice, as it has built-in Java support. What is key here is that you can start your Java journey with no investment, other than your time. Tools like IBM's VisualAge for Java (www.software.ibm.com/ad/vajava) offer robust Java development environments and productivity tools that are worth their price, but they are optional, not required. Much like SDA is optional for display file creation, not required (you can always use SEU). It is this low entry price that has helped push the number of Java programmers past the 700,000 mark in less than two years. The beauty of this technology is that you can take your 'class' file and run it anywhere the JVM exists. You don't even have to recompile it on the target platform. Hence, "write once run anywhere". Today, you are hard pressed to find an operating system that does not have a Java Virtual Machine. One day, your toaster will! This run anywhere benefit is reciprocal too - meaning you can find other people's classes on the web and download and use them directly. These classes typically come in the form of JavaBeans - these are simply Java classes that follow defined conventions to make them easily reusable.

A common question at this point is "what is the difference between a Java application and a Java applet?" They are essentially the same - both start with Java source that is compiled into Java bytecode. The difference comes at run time - applications are started from a command line using the "JAVA" JVM command, and typically have their own main windows, while applets can only be run inside a web page and use the real estate of the web browser for their user interface. References to Java applets are imbedded in web page HTML source via the APPLET tag, and are downloaded to the web browser when the HTML page is downloaded, and interpreted or run by the web browser's built-in Java interpreter. The compelling advantages of applets are that they offer a way to program user interactivity into your web page, and they are distributed "on demand" alleviating the client/server problem of distribution and servicing. Note that both applets and applications can access data from your server. For DB2/400, this is done using the JDBC driver package that is included in the AS/400 Toolbox for Java product.

The Java Anatomy

With all this said, how does Java differ from a language such as RPG IV? Lets start by 'peeling the onion'. The following figure illustrates the overall program unit or application. In RPG IV you create your RPG source code and then compile it to produce a *MODULE object. These are then "collected" and bound together to form a program (*PGM) or a service program (*SRVPGM). The program can be run directly, the service program is meant to be used by other program objects. Service programs are equivalent then to DLL files on the workstation, and programs are equivalent to EXE files on the workstation. In Java, your source code is compiled into bytecode .class files, which can be bound together to form a package. Typically, the first class in your application (like the CPP on the AS/400) is not part of a package, but then uses other classes in one or more packages. Packages then, are similar to ILE service programs. They allow you to collect commonly needed functionality (classes or modules) into an object that is easily reusable by others. In Java, you don't run a separate command to create a package, you simply identify via the "package xyz" statement in your source what package this class is to be part of. If you don't identify a package name this way, your class is considered to be part of the "unnamed" package. If we only use classes in unnamed packages for the initial program control, then we can think of these "unnamed packages" as being roughly equivalent to programs in RPG. They are what gets called from the command line by the user.  Photo: George Farr

In ILE RPG IV, source members are always compiled into *MODULE objects first, then these become parts of either programs or service programs. In Java, source files are always compiled into CLASS files first, then these become parts of either the unnamed package or of named packages. Thus, you see that from a compilation unit point of view, a Java class is equivalent to an ILE module. What is in an ILE module? How do you "call" them or use them? They contain variables (global to the module), mainline code, and something new for you - procedures. Procedures are grown up subroutines introduced in RPG in V3R2 and V3R6. They can be called directly from outside the module, and they can contain their own "local" variables and executable C-Spec code. They can also accept parameters and return a value. What is in Java classes? A Java "class" definition which includes variables (global to the class) and methods. Methods are the same as procedures - they contain local variables and executable code. Note that Java does not allow mainline code - all code must exist inside methods. Each class can contain a special method - called a constructor - that is the first method called by the Java system for this class. Thus, a constructor is roughly equivalent to a module's mainline code, or perhaps the *INZSR special subroutine in RPG.

For example, after you create a service program on the AS/400, you can just ship that to your customers for them to use the different entry points or procedures that the service program provides. You users are not aware of the modules that make up this service program, they are only aware of the procedure names. In the case of Java you ship them your package which contains the set of all Java methods you want them to use. These methods are inside classes, and unlike RPG, to use a Java method you must "qualify" its reference with the name of the class that contains it. And you must qualify the class name with the name of the package that contains it (unless you "import" the package in your code). All this "qualification" is done using "dot notation". For example, myPackage.myClasss.myMethod().  Photo: Phil Coulthard at work

Given all of this, our next task is to go through the different language constructs in Java and compare them to RPG IV. Obviously we cannot cover all of the detailed comparison between both languages in this article (maybe we could if we were allowed 500 pages!). However, in upcoming issues, we will take you through step by step comparing the language constructs between Java and RPG IV. Notice that we use the RPG IV language to compare to Java since it is far more suited for this given the new capabilities in the language such as procedures, local fields, service programs, modules...etc. We heavily recommend you continue your path to RPG IV, even if you are thinking about Java, because the skills transfer to Java will be much easier. Throughout the series we will point out certain similarities or differences between Java and RPG IV. We take you through the overall program unit and the different pieces that makes up a Java applet or application and compare that with the RPG IV language that is familiar to you. We then go through all the language features such as data types, initialization, constants, conditionals, loops, casting, expressions, relational and logical operators, and compare them between both languages. Once all of this has been covered, we conclude the series by answering the question, "What makes a language OO?" As part of the answer we introduce objects in Java and the process of instantiating them (i.e. creating them) from class definitions. In addition, at one of the TUG meetings, we will give you a live demo of VisualAge for JAVA and show you how simple it is creating Java applications or applets using this tool. This topic is big enough for an entire book! Hmmm..... T < G