Type-Analysis

The current version of the HPJava type-checker (front-end) has three main phases; type-analysis, reachability analysis, and definite (un)assignment analysis. Development of this type-checker was one of the most time-consuming parts during the implementation of the whole HPJava compiler.

The first phase is type-analysis. It has five subordinate phases: ClassFinder, ResolveParents, ClassFiller, Inheritance, and HPJavaTypeChecker.

1. ClassFinder collects some simple information about top-level and nested class or interface declarations, such as names of the classes, the names of super class, and the names of super interfaces.

2. ResolveParents resolves class's proper super class and super interfaces using the information from ClassFinder.

3. ClassFiller fulfills a more complicated mission. It collects all of the rest of the information about top-level and nested class or interface declarations, such as field declarations, method declarations, constructor declarations, anonymous class allocations, and so on. ClassFiller also collects and resolves single-type-import declarations and type-import-on-demand declarations.

4. Inheritance collects and resolves the method inheritance, overriding, and hiding information to be used in HPJavaTypeChecker.

5. HPJavaTypeChecker does type-checking on statements, statement expressions, and expressions, including all ordinary Java, and the newly introduced HPJava constructs--multiarrays, etc.

The second phase is reachability analysis, carrying out a conservative flow analysis to make sure all statements are reachable. The idea of Reachability is that there must be some possible execution path from the beginning of the constructor, method, instance initializer or static initializer that contains the statement to the statement itself. The analysis takes into account the structure of statements. Except for the special treatment of while, do, and for statements whose condition expression has the constant value true, the values of expressions are not taken into account in the flow analysis.

The third phase is definite (un)assignment analysis. It consists of two parts, DefAssign and DefUnassign, which checks the definite (un)assignment rules for Java, implementing the flow analysis of the Java language specification.

The three phases are basically inspired by carefully organizing The Java Language Specification, Second Edition (JLS) [17]. The current HPJava type-checker system only supports exactly what JLS says (plus the HPJava extensions, of course). But the Java language itself keeps evolving in a slow manner. For example, Sun's SDK 1.4 Java compiler supports some changes to JLS, and the 1.5 release will add many more. We expect to update the HPJava type-checker system when the new edition of JLS is eventually published. Figure 5 shows the complete architecture of HPJava front-end.