|
How Jazillian Translates COBOL To Java Code
Jazillian takes the source files
that you provide and applies a series of transformation rules
to translate various COBOL constructs and patterns into their Java
equivalents, generating “natural” code. For more information,
see How Jazillian Translates Legacy Code to Java Code.
Example 1: "Hello, World"
This COBOL program:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY "Hello, world!".
STOP RUN.
Becomes the this Java program:
public class Hello {
public static void main(String[] args) {
System.out.println("Hello, world!");
}
}
In this case, Jazillian applied the following "rules":
- Because the PROGRAM-ID was "HELLO", the Java file "Hello.java" was created.
- The main() method was created by including all the code at the start
of the PROCEDURE division.
- The DISPLAY statement was changed to a System.out.println() call.
The key to Jazillian is that
it produces reasonable Java code.
Each of the three "rules" applied here illustrates this.
Jazillian makes reasonable assumptions about what programmers do.
Jazillian knows the rules for control flow in a COBOL program. In this case,
there was just one statement before the "STOP RUN" statement, which it put
into a Java main() method. In general, it will create a main() method
with all the appropriate code. COBOL paragraphs become Java methods, and COBOL
sections become Java methods with calls to the paragraphs in the SECTION.
COBOL statements generally translate to one or more Java statements.
Jazillian takes steps to generate realistic code.
Jazillian generates code that looks hand-written. Other tools that
translate COBOL code generate either XML, Java byte code, or unreadable Java code.
For example, one tool that generates Java code actually generates 62 lines of
code for this simple "Hello, world!" program, and that code is very difficult to
understand.
Jazillian makes reasonable guesses.
How did Jazillian know
to call the class "Hello"? It took the PROGRAM-ID, in this case "HELLO", translated
it to the Java class naming convention ("Hello"), and Jazillian knows
that each Java file name must match the class that it contains.
"Hello" may not be the perfect name for this class,
but it's as good a guess as a machine can do. Jazillian also generates code
that follows Java naming conventions for all variables, methods, and classes.
You can also specify your own mappings to specify your own names instead.
For example, rather than having variable "WS_MYVAR_NAME" be automatically
renamed to "wsMyVarName", you could provide your own name like this:
WS_MYVAR_NAME --> myVariableName
So even with the simple classic 3-line "Hello
world" program, the rules that were applied used
various "real-world programming" heuristics into account
to produce "real-world" Java code. It was not enough
to produce correct, working code. In fact, Jazillian will not always
produce correct, working code But the
code looks like it was written by a good Java programmer,
not by a machine. This philosophy of "use heuristics to
produce realistic code" is inherent in the design of Jazillian
and most of its rules.
Example 2: COBOL Data
Consider the following data in a COBOL WORKING-STORAGE SECTION:
01 EMPLOYEE.
05 NAME.
10 FIRST PIC X(12).
10 MIDDLE PIC X.
10 LAST PIC X(10).
05 AGE PIC 999.
05 SEX PIC X.
Jazillian creates a Java class for each COBOL record (i.e. "group"), and a Java field for each
COBOL field. So it generates:
class Employee {
Name name;
int age;
String sex;
}
...and...
class Name {
String first;
String middle;
String last;
}
This process of generating Java data structures from a COBOL WORKING-STORAGE section
is highly customizable. For example, we could configure Jazillian to "collapse" the
NAME group, producing:
class Employee {
String first;
String middle;
String last;
int age;
String sex;
}
Jazillian also generates Java code that allows the application to behave
exactly like the original. For example, if a field is to be displayed or input
in a particular format, it may have a fairly complex PICTURE clause. Jazillian
generates a constant which "knows" how to format that data field, like this:
public final static FieldFormat middleFF = new FieldFormat("middle",
"X", FieldFormat.DISPLAY_ENCODER);
and that constant may then be used like this:
System.out.println(middleFF.format(employee.middle));
Example 3: The PERFORM statment
The COBOL PERFORM statement is a good example of how a single COBOL statement may
end up producing a wide variety of Java code, depending on the form of the COBOL statement.
A single COBOL PERFORM statement may get translated to a "while" loop, a "for" loop,
a "do-while" loop, a sequence of method calls, or a single method call. Here are some examples:
A PERFORM statement with a VARYING clause gets translated to a "for" loop:
PERFORM STEP1 THRU STEP3 VARYING COUNTER FROM 2 BY 2 UNTIL (DONE) END_PERFORM;
...becomes...
for (counter=2; !done; counter += 2) {
step1();
step2();
step3();
}
PERFORM STEP1 THRU STEP3 UNTIL (DONE) END_PERFORM;
...becomes...
while (!done) {
step1();
step2();
step3();
}
PERFORM v1 THRU v2 TEST AFTER UNTIL (DONE) END_PERFORM;
...becomes...
do {
step1();
step2();
step3();
} while (!done);
d += c;
|
Home
The Jazillian Solution
