Main issues to be addressed in a FORTRAN-to-Java converter

Although it is true that translating a FORTRAN program to Java program is relatively easier than other way around, some issues have to be dealt carefully for both semantical equivalence of the corresponding programs and efficiency of the resulting Java program. Our experience has shown that some of the issues are non trivial. In fact, we have not reached satisfactory solutions for some of them. In this section, we briefly introduce the main issues that have been addressed in our converter. We describe our translation schemes for each one of them in the next section.

• Naming convention.

  Basically, there are two kinds of names in the resulting Java program. One is type name, i.e., class name; the other is variable name. It is obvious that majority of those names should be derived from names in the input FORTRAN program, based on some convention. Moreover, some additional names have to be created to compensate the discrepancies of the two languages.

• Correspondence between FORTRAN program units (main program, subroutine subprogram, function subprogram, and block data subprogram) and Java classes.

  In fact, this is one of our basic decision, namely making a one-to-one correspondence between FORTRAN program units and Java classes. It may be conceivable to design a many-to-one scheme. But we thought it would make things complicated, though some benefit of it is observed.

• The matching of function/subroutine calls in FORTRAN and method invocations in Java.

  The basic problem is that FORTRAN passes arguments by address, while Java passes arguments by value for primitive data types and by reference for general objects.

• Differences in data types.

  Although Java provides a rich type system and FORTRAN is very primitive in this regard, to effectively represent FORTRAN types in Java needs some design.

  In particular, FORTRAN array presents a major problem. In FORTRAN, array is not really a distinct data type. Instead, it's an `non encapsulated memory region'. Programmers are allowed to do various `tricks' within that region, for instance, forming another array from part of the region through subprogram interface. In Java, an array is an object. One can not assign new meaning (give a name) to a part of the object.

• FORTRAN specific statements.

  FORTRAN has some statements, such as GOTO, COMMON, EQUIVALENCE, and various I/O statements, etc., which are not present in modern languages. We need to find proper Java correspondence for them.

In what follows, our discussion will be focused on translation schemes for the above issues. Coding details will not be discussed, since it is closely related to the data structure of the AST.