Report program language source code translation to object-oriented language source code which emulates report program language behavior

[0002] 1. Field of the Invention

[0003] This invention relates generally to the field of high level computer programming languages and translating source code in one computer programming language to source code in another high level language for compilation, and more particularly to the translation of VisualAge® Report Program Generator (VARPG) source code to Java® source code. VisualAge is a trademark of International Business Machines Corporation and Java is a trademark of Sun Microsystems.

[0004] 2. Description of the Related Art

[0005] Businesses have invested money, time, and resources in computers and computer systems which store and access large quantities of data relating to specific matters, such as financial accounts, inventory, customers, employees, etc. Businesses are sensitive to the loss of their investment when new computer technology arises which may result in their investments becoming obsolete. An important consideration, therefore, in introducing new computer technology is adapting it to interface with existing computer technology.

[0006] A computer database is the organizational structure in which large quantities of data are stored and managed to facilitate efficient storage, search, retrieval, and use of the data in the database. Computer scientists and other researchers have developed a number of different conceptual models under which databases may be constructed. The most prevalent database model created by business programming languages is known as a relational database. In a relational database the data are typically organized in tables and each data element in a table is indexed by its row and column in the table. The programmer who creates the database has considerable latitude in specifying the rows, columns, keys, and other characteristics that define the schema of a relational database. The above-described data model underlying relational databases was developed to facilitate the storage and retrieval of data under the control of procedural or structured programming languages, such as the Report Program Generator (RPG). Because procedural programming languages and relational databases were for many years being developed and improved upon contemporaneously with one another, procedural languages are well-suited to manipulating relational database data. For example, most procedural programming languages allows a programmer to access an element of a table by specifying its row and column. Although a program would not necessarily access a database element using that feature of the programming language, the point to note is that relational schema and procedural programming share common concepts and programming philosophies.

[0007] Another type of programming, known as object-oriented” programming (OOP), is becoming increasingly popular and may eventually supplant procedural programming. OOP languages, such as Smalltalk, C++, and Java, allow programmers to approach their programming tasks in a way that is believed to be more natural and intuitive than the rigidity of the procedural programming languages. A potential problem, however, is that OOP languages do not inherently interface smoothly with relational databases in which businesses may have a substantial investment. For example, the concept of indexing a table of data elements by row and column is in itself somewhat at odds with the OOP philosophy of handling an object in accordance with what it represents rather than how it is represented in a rigid data structure. The goal of OOP is to reduce the time and costs associated with developing complex software by creating small, reusable sections of program code that can be quickly and easily combined and reused to create new programs. The code sections are known as objects. The software object may model the attributes or characteristics of the real-world object and, in many cases, may also model its behavior. For example, an OOP employee object may have certain attributes of a real employee, such as a name, an address, an employee number, and so forth. Exploiting the full capabilities of the OOP source code, the employee object could be used in a program corresponding to the way one would interact with a real employee. For example, the employee object could provide the employee's address when asked for that information or provide the employee's status, e.g., “on vacation,” when asked for status information.

[0008] Object-oriented databases (OODBs) that are specifically designed to facilitate storage and retrieval of objects have been developed. Objects that are stored in a data store are known as persistent objects because they “persist” after the program that created them ceases executing.

[0009] Despite the recent development of dedicated OODBs, businesses have invested billions of dollars over the years in their existing or legacy relational databases so it would be an extraordinarily uneconomical task to transfer all legacy relational data into OODBs. Furthermore, relational databases continue to be viable; they are continuously developed and improved and remain commercially available.

[0010] Thus there is a need for object-oriented programming to access and interact with relational databases.

[0011] There is also a need to enable programmers skilled in procedural programming languages, such as Report Program Generator, to take advantage of electronic business on the Internet and the world wide web using such object oriented programming as Java applications while in the context of RPG language.

[0012] A computer-implemented method for generating source code in an object-oriented language from a report generator language source code is provided wherein the method comprises the steps of naming a class for the source code in the object-oriented language and generating internal instance variables used in emulating report generator language behaviour in the object-oriented source code. The method further converts global fields of the report generator language to instance variables, and specifications for input/output formats of the report generator language to object-oriented methods for reading and writing records, and a calculation specification to object-oriented methods. A constructor that creates and initializes the global fields, and object-oriented methods for error detection and correction are generated. The method may further comprise generating a main method in the object-oriented language, as well as generating methods to interface with a GUI.

[0013] The report generator language may be VARPG and the source may be a NOMAIN project or a VISUAL project, or an EXE project. The object-oriented language to which the projects are converted may be Java. The input/output formats of the report generator language may further be converted to object-oriented methods for reading, writing, clearing, and resetting records and windows.

[0014] The invention may further embody a computer-implemented method of calling Java methods from a report program language, comprising the steps of adding an Object datatype to the report program language wherein the Object datatype represents fields that can store a Java object reference. A CLASS keyword is added to the report program language wherein the CLASS keyword specifies the class of the Object datatype. This embodiment further adds an extension of the EXTPROC keyword to the report program language which specifies the name of the Java method to be called and class to which the method belongs.

[0015] Yet, the invention may further embody a computer-implemented method converting an RPG project to Java source code comprising the steps of naming a class and then generating internal instance variables used in emulating RPG behaviour in the source code in Java. Global fields of the report generator language are converted to Java instance variables and specifications for input/output formats of the report generator language are converted to Java methods for reading, writing, clearing, and resetting records and windows. A calculation specification is converted to Java methods and a Java constructor that creates and initializes the global fields is generated. Java methods for error detection and correction are also generated. If the RPG project is a VISUAL or an EXE project, a Java main method is also generated. The method may also comprise generating Java methods to interface with a GUI.

[0016] The invention may further be embodied in a computer system for converting a procedural language source code to computer source code in an object-oriented language, wherein the computer system comprises a central processing unit and a main memory connected to it with a communication bus network, a data storage unit connected to a data storage interface also connected to the communication bus network, and an input/output device connected to an interface as part of the communication bus network to provide input to the central processing unit. Optionally, the system may be connected to at least one network connection with which to communicate with a remote processor. The system would further comprise a procedural language compiler connected to the main memory and central processing unit wherein the compiler has a class namer to name a class for the object-orient source code, a generator to generator internal instance variables which emulate the procedural language, a global fields converter to convert global fields of the procedural language to instance variables, an I/O specification converter for converting input/output formats of the procedural language source code to object-oriented methods for reading and writing records, a calculation specification converter to convert any calculations in the procedural language source code to object-oriented methods, a constructor generator to generate an object-oriented constructor that creates and initializes the global fields, and an error detector and handler. The computer system would also have an object-oriented computer language compiler connected to the procedural language compiler to compile the object-oriented source code to control the central processing unit.

[0017] It is further intended that the invention may also be embodied in a program product for use in a computer system for generating object-oriented source code from a report program source code, with the computer program product having a signal-bearing medium carrying thereon and also having a class namer to name a class for the object-orient source code, an instance variable generator to generate internal instance variables to emulate report program behaviour, a global fields converter to convert global fields of the report generator language to instance variables, an I/O specification converter for converting input/output formats of the report generator language to object-oriented methods for reading and writing records, a calculation specification converter to convert any calculations in the report generator language to object-oriented methods, a constructor generator to generate a constructor to create and initialize global fields, and an error detector and handler.

[0018] The objects are further achieved by a computer-implemented method, comprising Java source code which allows Java applications to emulate behavior of report program language source code. The Java source code may comprise Java classes and may comprise any of the following: Component, GuiComponent, RpgLang, RpgNumeric, RpgPacked, RpgZoned, RpgBinary, RpgUnsigned, VarLenFld, RpgFile, DiskFile, PrinterFile, RemoteDiskFile, LocalFile, FixedLengthLocalFile, VarLengthLocalFile, RemoteKeyedDiskFile, RemoteNonKeyedDiskFile, SubfileFile, RpgRemoteCall, RpgDataArea, RpgDate, ExceptionHandler, RpgException, RpgFileException, and RpgEditNumeric.

[0019] Applications written in RPG are converted to Java and therefore can run on every platform for which a Java virtual machine exists. Thus, RPG programmers now have the ability to write internet applications. RPG source code is converted to Java source code in such a way that RPG specific behaviors are preserved. Java applications and applets can be written in RPG and existing RPG applications can be converted to Java applets.

[0020] The invention will further be understood by reference to the Drawings in which:

[0021] FIG. 1 is a simplified block diagram of a computer apparatus and system capable of taking advantage of the principles embodied in the invention;

[0022] FIG. 2 is a high level flow chart of a method of converting high level report program language to an object oriented language according to principles of the invention; and

[0023] FIG. 3 illustrates the architecture of the runtime environment and shows the references to object-oriented classes that the generated application class makes according to principles of the invention.

[0024] An Overview section is provided below for the benefit of readers who are not generally familiar with OOP technology. Readers who understand OOP may wish to skip the Overview section and proceed directly to the Detailed Description.

[0025] Overview

[0026] OOP differs from standard procedural programming in that it uses objects rather than procedures as the fundamental building blocks for creating computer programs. Both objects and procedures are embodied as sections of code that may be written in a high-level language. Nevertheless, how a programmer uses objects to design programs differs greatly from how a programmer uses procedures. The goal of both OOP and procedural programming is to break a programming task into smaller, more manageable sub-tasks. A procedural programmer may break a program into a hierarchy of procedures, each of which performs an algorithm, the procedures are generally not autonomous. So even though a procedure lower in the hierarchy could be re-used in a different program by a different procedure higher in the hierarchy, the re-use of code is not nearly as straightforward or intuitive as the re-use of objects.

[0027] A fundamental concept in OOP is the class. A class is a template or prototype that defines a type of object. A programmer may define a class by writing a section of code known as a class definition. An object is an instance of a class. An object is created or instantiated at runtime, i.e., when the computer executes a statement in the program calling for the instantiation of an object of a specified class. An object may include attributes or data as well as functions or methods. The class definition specifies the attributes and methods. The attributes are represented in an object by the values of instance variables.

[0028] Encapsulation, inheritance and polymorphism are three important concepts that differentiate OOP from procedural programming. Encapsulation refers to whether the class is public or private. Often, an object may perform its function without needing to reveal its implementation or internal data. A class definition may specify that the data of objects of that class is private and cannot be accessed by an object of another class. Public data can be accessed by an object of the class or subclass. Objects must communicate with one another via their object interfaces and the data may be encapsulated by limiting access to it through the object interface. Such data can only be modified by the object methods. Inheritance is the ability to derive a new class from one or more existing classes. The new class, known as a subclass, may inherit or incorporate all properties of a base class including its attributes and its methods. The new class or subclass may be defined to include additional properties. Objects communicate with one another by sending and receiving messages. A powerful concept of OOP, known as polymorphism, is that objects of different classes may respond to the same message in different ways.

[0029] Another concept that is featured in many OOP languages is known as aggregation or containment by value. A dependent is a type of aggregation. A dependent object differs from other types of objects in that it is not shared. Rather, a dependent object is contained within another object, which may be referred to as an entity to distinguish it from dependents and other classes of objects. A framework is a collection of base classes that extends the power of object-oriented systems. Stated another way, a framework is a set of cooperating classes that make up a usable, extensible architecture. A framework functions as the operating environment. A programmer can use the base classes to derive more specialized classes that represent business objects or entities. A persistent object is one that can be preserved beyond the termination of the process that created that object. A framework that supports persistent objects includes methods that allow persistent objects to be stored in and retrieved from a non-volatile data store, such as a magnetic disk or writeable optical disk. In the environment of a preferred framework, the dependent objects referred to in this specification are only persistent when contained in an entity. That entity “owns” the dependent. The life cycle of a persistent dependent object does not exceed that of its containing entity. When the containing entity is deleted, all of its contained dependent objects are deleted.

[0030] A suitable server computer is illustrated in FIG. 1 and may be programmed in any suitable manner that effects the functions described herein. The computer includes a central processing unit 36, a main memory 38, a data store manager 40, input/output (I/O) interfaces 42, and network communication interfaces 44. A network communication link 46 connects the computer to other computers, such as the client computer (not shown). A user may interact with source code generator according to principles of the invention via a keyboard 48, monitor 50 and a mouse 52. A removable-media disk drive 53, such as a floppy disk drive is also provided, and may be used for, among other purposes, storing the newly compiled Java code. Although data store 30 is illustrated as being integral to the server computer for purposes of clarity and convenience, it may be remotely located and accessed via network communication link 46. Similarly, the method described herein and/or the converted Java source code may be transmitted to or received from remote computers via network communication link 46.

[0031] The difficulties which arise in the translation from a program in one higher level language to a program in another higher level language principally result from the differences in the respective language structures and formats. The application program used as a preferred embodiment for description of the invention is Report Program Generator (RPG). RPG is a computer programming language designed to read and create reports from data base files. VisualAge Report Program Generator (VARPG) is a version of RPG that has a Graphical User Interface (GUI) and is compatible with a Windows® environment (Windows is a trademark of Microsoft Corporation). VARPG is a fixed format language and is comprised of a main program and subprocedures. The main program has a number of specifications in order. First, the control specification defines the type of VARPG project and sets up options for compiling, for arithmetic, for the environment, e.g., date and timestamp formats, etc. Following is the file specification which states what files are to be used. The definition specification then defines the global variables whereas the input specification defines the record format of the files being used. The calculation specification defines the user logic. The output specification defines the record formats of the output files. The main calculation specification is contained in action and user subroutines. User logic can also be contained in subprocedures which are not considered part of the main calculation specification. Subprocedures are analogous to functions in other programming languages.

[0032] VARPG has three types of projects. The first is a VISUAL project having a GUI. It has a main calculation specification, i.e., it can contain action subroutines and user subroutines. It can also contain subprocedures. The second project is referred to as NOMAIN which can only contain subprocedures. It does not have a main calculation specification or a GUI. The third project, the EXE project, can only contain subprocedures. One of the subprocedures is considered to be the main subprocedure which allows the EXE project to be run by itself like a batch program. An EXE project does not have a main calculation specification or a GUI.

[0033] An RPG compiler, preferably a VARPG compiler, has been modified so that it can generate source code in an object oriented language from VARPG source code. In the preferred embodiment, the example of object oriented language is Java from Sun Microsystems, although it is to be understood that other OOP languages may utilize the principles of the invention. The generated Java source code can then be compiled by any Java compiler to produce a Java class file as an application or applet. RPG behavior is preserved as much as possible in the Java object so that when the application or applet runs, it behaves as an RPG programmer would expect. The RPG specific behavior that has been preserved includes: record I/O, exception handling, most datatypes, and most operation codes. VARPG source code compiled to a Windows object code, and VARPG source code compiled to Java source code and ultimately to a Java application or applet will behave in a similar fashion when run. To preserve some features of the VARPG functionality, minor changes to the VARPG source code may be required. Some RPG features, however, are not supported because the equivalent functionality is not supported in Java.

[0034] In FIG. 2, a high level block diagram of the preferred embodiment of the invention is presented. In block 200, the VARPG compiler reads the VARPG source code file, checks the syntax of the code, and generates an intermediate language. Still in block 200 in an extended diagnostics phase, the VARPG compiler checks the semantics and modifies the intermediate language if necessary. Until now, the compiler performs in a typical manner known to those skilled in the art of compilers and intermediate languages. In the code generation phase in block 210, the VARPG compiler generates Java source code, block 220, from the intermediate language. The VARPG compiler then invokes a Java compiler in block 230, specified by the user to compile the generated source code to a Java class file in block 240. The code generation phase 210 of the compiler has been enhanced so that if the compiler is invoked with the Java compile option (/j), the target of the compilation is a Java source file and a Java class file. The user can specify what Java compiler they would like to use for the Java compilation. If none is specified, the Java compiler from Sun Microsystems is assumed.

[0035] The generated Java class file makes heavy use of the VARPG compiler runtime, which in turn makes use of the VARPG GUI runtime and VARPG host services layer, preferably a modified version of the AS/400® Java Toolbox (AS/400 is a trademark of International Business Machines Corporation). Both the VARPG compiler runtime and the VARPG GUI runtime have been translated to Java for this purpose. The generated class file also requires several standard Java class files to run.

[0036] FIG. 3 is another high level block diagram of an embodiment of the invention. In Block 310, a VARPG application class has aspects which must be considered when generating Java source code. The user logic from VARPG statements includes action subroutines for GUI events, user subroutines and subprocedures. User logic also references files used by the program. The generated Java program may move program fields in and out of file record buffers, must include GUI runtime interface methods, and may have initialization routines which initialize program variables and the application, as well as termination routines. If the application program itself has variables, the Java source code must also accommodate these variables and there must be logic for error detection and correction. To accommodate VARPG behavior, the application class use runtime classes 320 which include common RPG routines, RPG file classes and RPG datatype classes. Java GUI runtime classes 330 were also created for Visual projects to control the display and appearance of graphic parts, handle user actions, invoke the action subroutines as necessary, and maintain data values of graphic parts. Toolbox classes 340 uses files and calls programs of a server operating system and classes 350 which are written by the user are called by an application class.

[0037] The VARPG Runtime Classes

[0038] A key feature of this embodiment of the invention is the creation of the following Java runtime classes which preserve VARPG behavior when running the application class. A brief description of the class is presented.

[0039] Mapping of VARPG Datatypes to Java Datatypes

[0040] VARPG datatypes are converted or mapped to Java datatypes. A byte array was chosen for character data over StringBuffer or char array to ensure the length of the field remains static throughout execution of the program. The use of byte array also maintains the same number of bytes of storage as the equivalent VARPG datatype. Because there is no equivalent Java datatype for numeric types Binary, Packed, Zoned, and Unsigned, these datatypes are represented by runtime classes that are all subclassed from the class RpgNumeric which contains the bulk of the methods to support their RPG behavior. These subclasses ensure that both the whole number portion and the precision of the numeric value fits into the declared size for the field.

[0041] In VARPG, null capable fields are implemented as a field value and a separate indicator value which indicates if the field should be considered to have a null value at the moment. The Java source code conversion implements a similar design. Null-capable fields are handled as if they were normal fields but are provided with a separate null indicator value. This null indicator is set and used when the field is read or written to a corresponding null capable field in the remote server, preferably an AS/400, file. The null indicator value is available to the application programmer for checking, and setting, just as it is when targeting a Windows object.

[0042] The mapping of VARPG datatypes to Java datatypes is presented in the following table.

[0043] Translation of Operation Codes

[0044] The vast majority of VARPG operation codes are executed by calling into one of the runtime classes. The methods in the runtime classes have been implemented in such a way that the expected VARPG behavior will occur when the operation is executed. When the VARPG source code calls a non-Java external procedure, such as a C function, the appropriate Java source code is generated for a function call through the Java Native Interface (JNI). The application programmer is responsible for providing the appropriate call target program on the native system side, in accordance with the JNI specifications.

[0045] Translation of Builtin Functions

[0046] As for operation codes, most of the Builtin functions are evaluated by calling into the runtime classes.

[0047] Implementation of Host (Remote) Files

[0048] The method of generating Java source code from VARPG code described herein may be implemented on any server, preferably an AS/400. The actual source conversion occurs on a Windows platform, although the invention could be implemented on any platform. The AS/400 Toolbox for Java provides Java class support for AS/400 database file access and AS/400 program calls and so the VARPG runtime classes that support host file operations also use the AS/400 Toolbox for Java support. The AS/400 Toolbox classes have been enhanced to support a full range of RPG file operations. The runtime uses the AS/400 Toolbox classes. The generated Java source code handles field movement between program values and record buffers but still calls VARPG runtime class methods for file operations.

[0049] Exception Handling

[0050] When an RPG runtime error occurs, the RPG compiler first checks for an error indicator or error operation code extender. If the error indicator or error operation code extender is present, it is set and the method continues to execute from the next RPG statement. If there is no error indicator or error operation code extender there is a check for the Program Status SubRoutine (*PSSR). If the subroutine is present, then the method will call it and the user will indicate where control should resume in the VARPG code. If neither the error indicator or error operation code extender nor the *PSSR is present, the default exception handler is called. The default exception handler displays an error message in a dialog box and the user will respond to several choices. This behavior must be maintained in the Java application. An implementation with C uses setjmp/longjmp whereas in Java, the try/catch model must be used.

[0051] Two exception subclasses were designed: a general RPG exception class and a file error specific class. These exceptions occur when errors are detected both in the generated Java source code and in the VARPG runtime classes. Java source code is generated to handle the exceptions according to the presence of error indicator or error operation code extenders, and presence of a *PSSR subroutine (INFSR subroutine for file errors).

[0052] Generation of Java Source Code from VARPG Source Code

[0053] The creation of the basic building blocks for the generation of the Java source code from the VARPG source code have been delineated. Now it is time to see how the RPG compiler actually generates the Java source code from RPG source code. In designing the generated source code, the following decision points are maintained: (1) structure of the generated Java source; (2) the VARPG runtime classes; (3) exception handling; (4) datatypes; (5) translation of operation codes; and (6) translation of builtin functions.

[0054] The Java source code generated from the VARPG source code is based on one of the following models, depending on the type of VARPG project. The italicized lines of code below represents a sample skeleton of the generated Java source code. Recall that VARPG has three components or project types: VISUAL, NOMAIN, and EXE.

[0055] For a VARPG VISUAL project, a component name is given to the Java public class that will be generated.

[0056] public class <ComponentName>

[0057] {

[0058] The VARPG compiler then generates the Java instance variables, which most likely are private but in some instances could be public. These instance variables are internal variables which preserve the VARPG behaviour in the Java source code and are generated for every application.

[0059] //Compiler generated instance variables

[0060] private . . .

[0061] private . . .

[0062] All the VARPG global fields are converted to Java instance variables.

[0063] //All global fields are converted to instance variables

[0064] private . . .

[0065] private . . .

[0066] The VARPG compiler than generates the main method, i.e., the main initialization function.

[0067] //main method starts the GUI runtime and exits

[0068] public static final void main( )

[0069] The translation then converts the input and output specifications of the VARPG project. In Windows, this stage is usually invisible to the user but with the program herein described the input and output specifications are exposed.

[0070] //Methods for reading and writing records and windows and

[0071] //methods for clearing and resetting records and windows

[0072] private internalMethod1( . . . )

[0073] private internalMethod2( . . . )

[0074] The action subroutines and user subroutines, that contain calculation specifications, are converted to Java methods.

[0075] //Action subroutines and user subroutines

[0076] public actionSubroutine1( . . . )

[0077] public actionSubroutine2( . . . )

[0078] private subroutine1( . . . )

[0079] private subroutine2( . . . )

[0080] //Subprocedures

[0081] private procedure1( . . . )

[0082] private procedure2( . . . )

[0083] Then, a constructor method for the application class is generated. The constructor instantiates and initializes the global variables.

[0084] //Constructor

[0085] public ComponentName( )

[0086] The methods required for interfacing with the GUI runtime are generated. These methods are not generated from user logic, i.e., they are not present in the VARPG source code.

[0087] //Methods required for interfacing with GUI runtime

[0088] public initializeComponent

[0089] public queryVersion

[0090] public componentInitialized

[0091] public closingComponentObjects

[0092] public terminatingComponent

[0093] public processActionSubroutine

[0094] Last, a method to handle errors is generated.

[0095] //Methods required for exception handling

[0096] private handleException( . . . )

[0097] }

[0098] For a VARPG NOMAIN project, the code generation phase does not generate any Java source code for the main method, for running or interfacing with GUI runtime, or for the action and user subroutine calculation specification because a NOMAIN project does not have these functions. Therefore, code generation for a NOMAIN project is simplified.

[0099] public class <ComponentName>

[0100] {

[0101] //Compiler generated instance variables

[0102] private . . .

[0103] private . . .

[0104] //All global fields are converted to instance variables

[0105] private . . .

[0106] private . . .

[0107] //Methods for reading and writing records and windows and

[0108] //methods for clearing and resetting records and windows

[0109] private internalMethod1( . . . )

[0110] private internalMethod2( . . . )

[0111] //Subprocedures. Private if not EXPORTed, public if EXPORTed

[0112] private/public subprocedure1( . . . )

[0113] private/public subprocedure2( . . . )

[0114] //Constructor

[0115] public ComponentName( )

[0116] //Methods required for exception handling

[0117] private handleException( . . . )

[0118] }

[0119] For a VARPG EXE project, the code generation phase does not generate any Java source code for running or interfacing with GUI runtime because an EXE project does not have these functions. Therefore, code generation for a EXE project is also simplified. Note that for both NOMAIN and EXE components, any initialization that is normally performed in the initializeComponent method of VISUAL projects takes place in the constructor.

[0120] public class <ComponentName>

[0121] //Compiler generated instance variables

[0122] private . . .

[0123] private . . .

[0124] //All global fields are converted to instance variables

[0125] private . . .

[0126] private . . .

[0127] //Methods for reading and writing records and windows and

[0128] //methods for clearing and resetting records and windows

[0129] private internalMethod1( . . . )

[0130] private internalMethod2( . . . )

[0131] //main method

[0132] public staticfinal <type> main( . . . )

[0133] //Subprocedures. private if not EXPORTed, public if EXPORTed

[0134] private/public subprocedure1( . . . )

[0135] private/public subprocedure2( . . . )

[0136] //Constructor

[0137] public ComponentName( )

[0138] //Methods required for exception handling

[0139] private handleException( . . . )

[0140] }

[0141] For all component types, the compiler generated instance variables which preserve the VARPG behaviour include:

[0142] Calling Java Methods

[0143] It is useful to call Java methods from RPG. In order to do so, the VARPG compiler needs to know the following information: (a) the name of the method; (b) a syntax to specify a class name and a method signature; (3) if the method returns an object, the class of the returned object; (4) whether the method is a static method; and (5) the datatypes of the parameters passed to the method. If the method, moreover, is not a static method, then an object must be instantiated in order to call the method. If the method returns an object, then the compiler must have somewhere to store the returned object. If the method requires an object as a parameter, then there must be some way to create that object. One way to accomplish this is to add to the VARPG language the following: (a) the Object datatype; (b) the CLASS keyword; and an extension of the EXTPROC keyword.

[0144] Fields that can store objects are declared using the new ‘O’ datatype. When declaring a field of type ‘O’, ‘O’ must be coded in column 40 of the D-specification, and the class of the object must be provided using the new CLASS keyword. The CLASS keyword accepts two parameters: CLASS (*Java:class name), where *Java identifies the object as a Java object, the class name specifies the class of the object. The class must be a character literal, and the class name must be fully qualified. The class name is case sensitive. To declare a field that will hold an object of type BigDecimal:

[0145] D bdnum S O CLASS(*JAVA: ‘java.math.BigDecimal’)

[0146] To declare a field that will hold an object of type String:

[0147] D string S O CLASS(*Java: ‘java.lang.String’)

[0148] Notice that both class names are fully qualified and that their case exactly matches that of the Java class. Fields of type O cannot be defined as subfields of data structures. It is possible to have arrays of type O fields but type O tables are not allowed because tables have to be preloaded at runtime. Certain keywords cannot be used with the CLASS keyword.

[0149] The EXTPROC keyword has been extended and is used to specify the name of the method and the class to which it belongs. When prototyping a Java method, the expected format of the EXTPROC keyword is: EXTPROC(*JAVA or *JAVARPG:class name:method name) where *JAVARPG identifies the method as a Java method that was generated using VARPG. *JAVA identifies the method as a Java method that was generated from code originally written in Java, that is, not through VARPG. This distinction is important because methods generated from VARPG will allow certain datatypes to be passed by reference that normally cannot be passed by reference in Java. This allows the same source code to be used when targeting Windows and when generating Java source code. Both the class name and the method name must be a character literal. The class name must be a fully qualified Java class name and the method name must be the name of the method to be called; both are case sensitive. The extended form of the EXTPROC keyword can only be used when calling Java methods and will result in a compiler error if targeting Windows.

[0150] The datatypes of the parameters and the return value of the method are specified in the same way as they are when prototyping a subprocedure. The only twist on this is that the datatypes actually map to Java datatypes. The compiler maps VARPG datatypes to Java datatypes in the following way:

[0151] Zoned, Packed, Binary, and Unsigned datatypes do not appear in the table because these datatypes are not available in Java. If a Zoned, Packed, Binary, or Unsigned field is passed as a parameter, the VARPG compiler will do the appropriate conversion, but this will most likely result in truncation and/or loss of precision. If*JAVARPG has been specified as the first parameter of the EXTPROC keyword, meaning that the method being called was generated by VARPG, then Packed, Zoned, Binary, and Unsigned datatypes can be specified as the datatype of parameters and return values. This can only be done for methods generated by VARPG. Methods generated from code originally written in Java do not have the capability to accept or return Packed, Zoned, Binary, and Unsigned fields. When calling a method, the compiler accepts arrays as parameters if the parameter is prototyped using the DIM keyword. Otherwise, only scalar fields, data structures, and tables will be accepted.

[0152] If the return value of a method is an object, then the class of the object must be provided. This is done by coding the CLASS keyword on the prototype. The class name specified will be that of the object being returned. The class of the method being called is specified using the EXTPROC keyword.

[0153] If the method being called is a static method, then the STATIC keyword must be specified on the prototype.

[0154] In Java, some datatypes can only be passed by value. Datatypes that can only be passed by value are: int, short, float, and double. Parameters of these types must have the VALUE keyword specified for them on the prototype. If*JAVARPG has been specified as the first parameter of the EXTPROC keyword, meaning that the method being called was generated by VARPG, then these datatypes can be passed by reference and so the VALUE keyword is not required. Note that objects can only be passed by reference. The VALUE keyword cannot be specified with type ‘O’ Since arrays are seen by Java as objects, parameters mapping to arrays must also be passed by reference. This includes byte arrays.

[0155] The Java Integer class contains a static method called toString, which accepts an int parameter, and returns a String object.

[0156] In the above example, the EXTPROC keyword tells the compiler that the method was not generated by VARPG. It also indicates that the method name is ‘toString’, and that it is found in class ‘java.lang.Integer. The ‘O’ in column 40 and the CLASS keyword tell the compiler that the method returns an object, and the class of that object is ‘java.lang.String’. The STATIC keyword tells the compiler that the method is a static method, meaning that an Integer object is not required to call the method. The datatype of the parameter is specified as 10I, which maps to the Java int datatype, and because the parameter is an int, it must be passed by value, and hence the VALUE keyword is specified.

[0157] This method accepts two objects as parameters. ‘O’ is coded in column 40 of the D-specification, and the CLASS keyword specifies the class of each object parameter. The Java Integer class contains a static method called getInteger, which accepts String and Integer objects as parameters, and returns an Integer object.

[0158] Integer Integer.getInteger(String, Integer)

[0159] This method would be prototyped as follows:

[0160] The Java Integer class contains a method called shortValue, which returns the short representation of the Integer object used to invoke the method. The STATIC keyword is not specified because the method is not a static method. The method takes no parameters, so none are coded. The return value is specified as 5I, which maps to the Javashort datatype.

[0161] The Java Integer class contains a method called equals, which accepts an Object as parameter and returns a boolean. The return value is specified as N, which maps to the Java boolean datatype.

[0162] Creating Objects

[0163] In order to call a method that is not static, an object is required. The class of the object must be the same as the class containing the method. Objects are instantiated, or created, by calling the class constructor. The class constructor is not a static method, but it does not require an object to call it. The special method name *CONSTRUCTOR is used when prototyping a constructor.

[0164] Calling Java Methods

[0165] Java methods will be called using existing operation codes CALLP when no return value is expected and EVAL when a return value is expected. No new syntax is required. When calling a static method, an object is not required in order to make the call. But when calling a method that is not static, an object is required. The object to be used must be coded as the first parameter in the call. This parameter is not specified on the prototype, but is implied for all methods that are not static. This means that whenever a method that is not static is called, a minimum of one parameter must be specified.

[0166] To do a TRIM using Java instead of the VARPG %TRIM BIF, the trim( ) method found in the String class may be used. The trim( ) method is not a static method so a String object is needed to call the method.

[0167] Static methods are called in the same way, except that an object is not required to make a call. If the makealpha method above was static, the call would look like:

[0168] C EVAL fld=makealpha( )

[0169] CALLP is used when the method does not have a return value

[0170] The compiler will not attempt to resolve classes at compile time. If a class cannot be located at run time, a run time error will occur. It will indicate that an UnresolvedLinkException object was received from the Java environment. The compiler does not do any type checking of parameters at compile time. If there is a conflict between the prototype and the method being called, an error will be received at run time. It is very important that *JAVARPG be specified as the first parameter of EXTPROC if the method being called has been generated from VARPG. If this is not done, it is likely that one of the above two error situations will occur.

[0171] Restrictions and Run Time Behaviour Differences When Generating Java Source Code

[0172] The following VARPG language elements are not supported when generating Java source code:

[0173] In order to generate the Java source code, some changes may be required to the VARPG source. For instance, To/from notation is not allowed when defining data structure subfields. Exceptions to this are when defining subfields of the PSDS and INFDS. In fact, the to/from notation must be used when defining subfields of the PSDS and INFDS in order to allow the compiler to validate the subfield definitions. The definition of subfields in the INFDS and PSDS must match the definitions specified in the VARPG Language Reference. A compile time error will be issued if they do not.

[0174] There cannot be an unconditional LEAVE or ITER operation as anything other than the last operation in a loop, otherwise the Java compiler issues an error. If there is an unconditional LEAVE or ITER operation in a loop, all operations occurring after it in the loop should be deleted because they will never be executed.

[0175] When adding and subtracting date/time/timestamp durations, only values between maxint (2 147 483 647) and −maxint (−2 147 483 648) can be used.

[0176] Because Java does not allow int (10I), short (5I), float (4F),and double (8F) values to be passed by reference, Java code has to be generated by VARPG to retain this functionality for subprocedures being converted to Java. The code generated to accomplish this can cause Java compiler errors when the VARPG source contains subprocedures with multiple return points and receives integer or float parameters passed by reference.

[0177] More Restrictions and runtime behavior differences

[0178] The characters ‘*’, ‘#’, and ‘@’ cannot be contained in Java identifiers. Because of this, all occurrences of ‘*’ ‘#’ and ‘@’ in VARPG names will be changed to ‘_’. It is possible that this will result in duplicate names.

[0179] If a COMMIT or ROLBK operation is coded within an application that has no files, a severity 30 message (RNF7833) will be issued.

[0180] Because of the way that a local *PSSR is converted to Java, it is not possible to call a local *PSSR. Because GOTO is not supported, the only way to leave a local *PSSR and avoid the default handler is to code a RETURN operation.

[0181] There is no short circuiting of logical expressions so the order in which a compound logical expression is executed is not reliable.

[0182] Varying length fields are implemented as a class when converting to Java so they are not stored as documented in the VARPG Language Reference. Code that relies on a certain storage format way will not work.

[0183] Data structure subfields will not be initialized to blanks if there is no initial value provided, but will be initialized to a default value depending on the datatype of the subfield. The default value is 0 for numerics, blanks for character, and *LOVAL for date, time, and timestamp.

[0184] Varying length fields will have their length set to 0. If a length is specified for a data structure, it must match the total length of the subfields it contains, otherwise the compiler will issue a sev 30 diagnostic message.

[0185] Subroutines cannot be defined within subprocedures. The only exception is that a *PSSR can be defined within a subprocedure. Any subroutines within subprocedures should be moved outside the subprocedure. If the subroutine accesses local fields within the subprocedure, then either the fields need to be changed to global fields, or the subroutine should be changed to a subprocedure that accepts the local fields as parameters.

[0186] Unconditional LEAVE statements within DO loops are not supported. A Java compiler error will occur if this situation exists. Since an unconditional LEAVE within a DO loop means that the loop will only ever be executed once, the LEAVE should be removed and the code changed to remove the loop operation codes.

[0187] Using event attributes in fixed compound conditional statements currently causes Java compile errors. The equivalent freeform expression should be used instead and the code should be changed as follows:

[0188] An unconditional RETURN operation cannot be coded unless it is the last statement in a user subroutine, action subroutine, or subprocedure; otherwise, the Java compiler may report an error. SELECT statements can cause Java compile errors when they occur in subprocedures or contain RETURN operations and no RETURN is coded within the main body of the subprocedure. In general, a RETURN operation should be coded for all possible code paths of a subprocedure, otherwise the Java compiler may report errors.

[0189] Arrays cannot be passed by value to subprocedures.

[0190] Because of differences between the Windows and Java environments an application may run differently under Java than it does under Windows. The following areas are affected:

[0191] The %SCAN builtin function will return an integer result, in Windows, it returns an unsigned result; the truncate numeric build option is unreliable.

[0192] When an I/O exception occurs, the user will not be given the option to retry the operation.

[0193] Data structures are not treated as one large character field when the Java application is running which may cause unexpected results.

[0194] The format of binary, integer, and unsigned datatypes is handled differently for local files, e.g., when reading and writing local files the Java format of having the high order bytes being left most is assumed, whereas when running as a Windows application, they are right most.

[0195] Exception handling for subprocedures will behave the same as for action subroutines and the default error handler is called if there is no local *PSSR or INFSR and no error indicator or error operation code extender on the operation.

[0196] If an invalid date, time, or timestamp value is encountered when reading or writing a field to/from a file, the field will be set to the default value (*LOVAL) and no error is reported. Java can only handle a three digit millisecond portion in timestamps. When doing calculations with timestamps that use all six digits of the millisecond portion, i.e., they do not have milliseconds in the form 000xxx, the results might not be as expected.

[0197] Intermediate results in expressions are not limited to thirty digits. In fact, when running in the VARPG environment, no attention is paid to the precision of intermediate results.

[0198] Memory cannot be shared between components. If a component is started by another component via START, changes made to passed parameters are not reflected across components.

[0199] Integer overflow/underflow will not be reported. Float overflow/underflow will be reported as status 9999.

[0200] If an error occurs while a subprocedure in a NOMAIN or EXE application is being executed, and there is no error indicator or error operation code extender, or *PSSR, then the error will be reported back to the caller and handled by the caller. When running under Windows, the application would terminate.

[0201] Positioning a host file to Null-Valued Records when ALWNULL(*NO) has been specified results in CPF5035.

[0202] The following language elements are not supported when running a VARPG applet and will result in Java errors at run time: Printer files, Local files, Calling C functions, external subprocedures, EXEs. NOMAIN and EXE applications cannot be run as applets.

[0203] Although a specific embodiment of the invention has been described herein in some detail, this has been done solely for the purpose of illustrating the invention in various of its aspects, and it is to be understood that the foregoing description does not limit the scope of the invention. It is contemplated that various substitutions, alterations and/or modifications to the embodiment of the invention disclosed herein, including but not limited to those implementation options specifically noted herein, may be made to the invention without departing from the spirit and scope of the invention as defined in the appended claims.