Of course we want our transformations to be conservative in the sense that they strictly preserve the meaning of the input program. The rules we give for transformation of source code, based on the simplify algorithm just described, would probably be considered conservative in ``traditional'' languages. They may not be considered conservative in transforming strictly Java-like languages because they do not preserve the exact model of exceptions--they allow reorderings of code that could be detected by inspecting the values of program variables after an exception occurred.
In our framework this shortcoming could be remedied by modelling the throwing of an exception as a use of ``all variables''. Any expression that could throw any exception (e.g. an arithmetic division, a subscripting operation, a dereferencing operation, a method invocation) would be considered to directly read the value of all variables. An intuitive justification for this approach is that throwing an exception can cause control to pass to a catch or finally block that might read essentially any program variable that might have been assigned in the expression. In any case, the effect is that an operation that may throw an exception will never be reordered relative to a subexpression that might assign any variable.
Actually we are converting HPJava to Java, not Java to Java. HPJava is not exactly Java, and it is not a clear a priori requirement that it must treat exceptions in the rigid Java way. For now the HPJava translator follows the unmodified scheme described in this section.