Being able to analyse and transform source code with missing dependencies (henceforth referred to as incomplete code) is usefull when only parts of a large project are available or if analysis of complete projects would be too time consuming because of their size.

JTransformer supports working with incomplete code by creating PEFs even if a project contains Java compilation errors because of unresolved imports. However, in such cases the references to missing elements are marked in a special way explained below. You can adjust your analyses and transformations to deal with theses markers.

Error-tolerant fact creation is turned on by default. To turn it off for a particular JTransformer project right click on the project, select “Properties” from the context menu and then select “JTransformer”. Here you must first enable project-specific settings and then (de)select “Ignore unresolved dependencies”.

When ignoring of unresolved dependencies is turned on and JTransformer encounters an unresolvable reference it:

1. lets Eclipse report the respective compilation error
2. creates nevertheless the fact containing the unresolvable reference.
3. replaces the reference in the fact by a unary function term unresolved(name).

Its name argument is the unresolvable name, as demonstrated by the following example:

Source with unresolvable names	Generated PEFs viewed in the Factbase Inspector

Because the com.nothere.* package cannot be resolved, Eclipse adds an error marker at the import command and at each place where the NotHere class from the unresolved package is referenced. Although not illustated in the above screenshot, note that in spite of the error marker attached to the Java project in the Package Explorer the JT icon remains green, signaling that the fact creation has completed succesfully.

The FBI view of the generated facts shows that unresolvable names com.nothere.* and NotHere have been replaced by the dummy IDs unresolved('com.nothere.*') and unresolved('NotHere').

Most often all you want is to ignore unresolved references. In most cases you do not have to do anything special, since complex conditions will typically fail on non-existing elements. However, occasionally one of your analyses will return a term marking an unresolved reference where you would expect the ID of a referenced fact. In such cases, just extend your analysis by the condition that expresses that you do not want to accept such results.

Assume that you are calling a predicate that you implemented yourself, say my_analysis(A,B,C), and it returns B = unresolved(something). Then just add the condition B \= unresolved(_). That is, you replace the query

?- my_analysis(A,B,C).

by the query

?- my_analysis(A,B,C), B \= unresolved(_).

The above use of the \= operator expresses that the value of B must not be a term with functor 'unresolved' and arity 1. That is the common structure of all markers for unresolved references (as explained above).