|Summary: this page provides information about how the JEE Analyzer handles pure Java applications|
In the context of a pure Java analysis an analysis is defined in terms of:
CAST allows each analysis to use their own "core API libraries" and cannot run if system classes (i.e. "java lang.*") are not specified in the Classpaths field - see JEE - Analysis configuration.
Supported file types
The JEE Analyzer supports java source files (.java), class files (.class) and SQLJ files (.sqlj).
Java archives (.jar and .zip) cannot be specified as such as analysis files. To include zipped files, the archive that contains them must be unzipped first. On the other hand archives are supported as class path entries. However, for archive processing, software requires the "java" executable program (delivered with any SDK or JDK) to be installed and accessible via the "Path" system variable on the computer where the analysis is run.
All objects revealed by the analyzer are not only identified by their Java qualified name (including mangling to distinguish overloaded methods) but also by the full path of their corresponding definition file. This allows the reflection of dynamic class loading paradigm and distinguishes between several implementations of the same class.
Each analysis keeps for each file an image corresponding to a snapshot at the time when file was last processed within the current analysis. Consequently if a shared file is modified it needs to be analyzed in the context of each and every analysis that includes the shared file. All non-resynchronized analyses will otherwise reflect the file as it was before modification.
Run Time Prediction (Inference Engine)
The J2EE Analyzer uses an inference engine to compute run time type information in order to simulate program behaviour during its execution. To find out more about activating and deactivating it in the CAST Management Studio, see JEE - Analysis configuration. This information is used to address the two following issues:
- Resolution of virtual calls
- Evaluation of character strings
Virtual call resolution
Method calls are de-virtualized by computing the actual run time type of the object on which invocation is performed. Software navigates from instantiation sites to method calls using executable paths. In case of alternatives both branches are considered so that all run time possibilities are retained.
On anObject.foo() software will trace a call towards I.foo() by compile time type analysis but will also trace dynamic calls towards A.foo() and B.foo() using run time type information.
String evaluation is used within the Parametrization feature (see the JEE Analyzer - Environment Profiles) to compute the actual value of arguments of parametrized methods. Here also all possibilities are evaluated and all possible links are traced accordingly.
On doSelect("Table") software will trace a "Use Select" link towards table MyTable if any.
Applet and SQJ support
Whenever an applet is detected (either via an HTML <APPLET> tag or via a class extending java.applet.Applet) an applet component is created in the Analysis Service. Applets are identified by the full path of their corresponding class file. The Prototype link is traced between the applet and its applet class.
The JEE Analyzer supports the SQLJ extension. It does not preprocess code to its JDBC equivalent as the SQLJ translator does, instead, it enriches underlying roadmaps with objects implicitly defined by SQLJ declarations.
- SQLJ declaration: iterator (named and positional) and context declaration both with "implements" and "with" clauses
- SQLJ executable statement: statement or assignment clause
Implicit Inheritance is recreated as follows on each declaration:
- public <context name> ( java.sql.Connection )
- public <context name> ( sqlj.runtime.ConnectionContext )
- public <context name> ( java.lang.String , boolean )
- public <context name> ( java.lang.String , java.util.Properties , boolean )
- public <context name> ( java.lang.String , java.lang.String , java.lang.String , boolean )
While processing SQLJ clauses, Java host expressions, context expressions and result expressions are passed to the analyzer as normal Java code. At the same time, the embedded SQL code is scanned for server side object references using dynamic link resolution algorithms as explained in the corresponding section.