As Java gets its dominance in Internet programming, it is natural for people to consider how Java may also be used in scientific and engineering computations. As Joe Keller, director of marketing and support/workshop products at Sun, indicated: while the first Java versions were built for portability, the next versions will be built based on performance [10].
Making Java faster is necessary for exploiting full potential of Java language for Internet applications, and many research groups and venders are pursuing various technologies to improve Java's performance. These technologies include, but are not limited to, JIT compilation, optimizing compiler, parallel interpretation, and parallelization of source code, etc. [11]. Thus, Java will be fast, and the faster Java gets, the more scientific and engineering problems can be solved in Java -- taking Java's well known advantages, and with acceptable performance. After all, Java now is faster than FORTRAN 20 years ago, and people were doing pretty good science and engineering with FORTRAN then.
While observing that computers are never fast enough to meet the requirements of leading edge science and engineering work, it should be safe to say that many circumstances where FORTRAN is used are not really time critical.
For more than 30 years, FORTRAN is still the fastest language for number crunching. But it seems a tradition that people like to build converters that translate FORTRAN programs to whatever popular languages. Besides the famous f2c maintained at Bellcore [7], there was also a FORTRAN to Pascal converter [9] when Pascal was popular. And there are some companies, part of their businesses is to convert FORTRAN programs to others [7]. Any way, there are some good reasons for turning FORTRAN to something more promising. Java's platform neutralness and mobility make it a more attractive language to turn legacy code into.
Thus, we have embarked on the effort of building a FORTRAN to Java converter, with a belief that Java is certainly more useful than Pascal, and will be more widely used than C.
From implementation point of view, the converter is based on HPFfe [1] and a previous FORTRAN-to-C conversion work done by one of the authors [8]. HPFfe constructs an abstract syntax tree (AST) for input FORTRAN program, a FORTRAN-to-C conversion module then turns this AST to a C counterpart. An enhanced unparsing process finally spells out a Java program from this intermediate AST. Thus, we observe the following process:
It seems weird to have a C AST involved in the middle. A more natural approach would be defining an intermediate representation (IR) for Java, and turning the AST for a FORTRAN program to the Java IR, followed by a straightforward Java unparsing. The path we took is merely for our convenience, since a FORTRAN-to-C module is already there, working with HPFfe in concert, and there is not much difference between C and Java.
From user's point of view, an application in FORTRAN consists of multiple source files, and each file has one or more program units. F2j takes as input a FORTRAN source file, say module1.f, and turns it into a semantically equivalent Java source file module1.java. Each FORTRAN program unit is translated into a Java class in the file. At the moment, no package information is incorporated in the Java source. Thus, the unnamed default package is assumed.