Integrations (PTC products, 3rd party products and code) > Code integration (Ada, ARINC 653, C, C#, C++, IDL, Java, SQL and VB) > Java code > Reverse engineering legacy Java code > Overview of reverse engineering legacy Java code (Java code) > Overview of reverse engineering legacy Java code (Java code)
  
Overview of reverse engineering legacy Java code (Java code)
Java Code Reverser (Reverser) is designed to reverse engineer legacy Java code into a model.
The Synchronizer allows you to reverse engineer compilable Java code to a model, which you may want to do for the following reasons:
To view the structure of the Java code in Modeler.
To develop the Java code further in Modeler before regenerating the code.
To move the Java code to another platform, such as Ada or C++.
To reuse all or part of the Java code in other models.
* 
Important: Java Code Reverser is not designed to round-trip code that is generated through ACS.
To use Java Code Reverser, you require an ACS license, a Modeler license and an ACS Language Pack for Java license.
Tip: You can reduce the time taken to reverse engineer code by having write access to the Model and all Packages in that Model.
Root Object and Root Directory
On the Select Model page of the Synchronizer, you specify a root object (the Model or a Package) in the Model and a root directory in your file system. The root object and root directory are used as a basis of package construction in the Model.
* 
Warning: Do not include any of the source code package structure in the Root Directory. If you do, the Synchronizer treats the Java files you select for reverse engineering as unmapped files and does not reverse engineer them.
If you want to reverse engineer a code file that does not reside in the root directory or one of its subfolders, you are prompted to map a parent folder of the code file to a Package in the Model.
Command Line Interface
The Synchronizer has a command line interface that allows you to reverse engineer code through a batch file. This is useful when working with a large model, because you can schedule a batch file to reverse engineer code over night. For more information, click here Command line interface (Java code)
Java Profile package
If you reverse engineer Java code to a Model, the Synchronizer creates a Java Profile package in that Model. The Java Profile package contains Stereotypes and Tag Definitions that are used against model items created by the Synchronizer.
* 
Important: If the Synchronizer creates the Java Profile package in a model, the profile may be incomplete and the Description property of each Stereotype and Tag Definition in the profile is blank. If you want a complete Java profile and the Description property of each Stereotype and Tag Definition to describe its purpose, you must import the supplied Java Profile package. If the Synchronizer creates the Java Profile in a model, you can add the descriptions by adding the supplied Java Profile package.
* 
Warning: If you want to add additional Tag Definitions to items in the Model, do not do so through the supplied Java Profile package. If you add Tag Definitions to the supplied Stereotypes, they may be unlinked when reverse engineering code. In addition, if you import the Java Profile package again or upgrade the Synchronizer, the Java Profile package will be overwritten.
Mapping information
For information about how model elements map to Java code, click here Summary of mappings for Java code (Java code)
Method bodies
The Reverse Engineer Code Bodies check box (Reverse Engineering Options 1 page) determines whether method body code is reverse engineered:
If the Reverse Engineer Code Bodies check box is cleared, the Synchronizer does not update the Operation Body properties in the Model.
If the Reverse Engineer Code Bodies check box is selected, the Synchronizer updates the Operation Body properties with associated method body code.
* 
Note that blank method body code will result in the associated Operation's Body property being made blank.
When updating Operation Body properties, the Synchronizer attempts to preserve model object references.
Search paths
The code files you select for reverse engineering may be dependent on other code files, such as library files. The Synchronizer parser needs to know the paths, zip files or jar files in which dependent code files reside to correctly parse the code files selected for reverse engineering.
When you specify a search path for a dependent file, you can optionally map the folder to a Package in the Model. If a referenced file is found in a search path outside of the root folder, the referenced file is reverse engineered only if the search path is mapped to a Package in the Model.
* 
Important: You must ensure that the Library Search Path check box is selected for each path. If the Library Search Path check box is cleared and the path is not mapped to a package, the path is ignored.
Name Clashes
When the Synchronizer reverse engineers code, the name of each model item is set to that of the reverse engineered element. If you have code elements whose names differ only by the case of the characters, this can result in a name clash in Modeler.
When there is a name clash, the Synchronizer uses the CODE_GENERATION_NAME property (appears on the Text tab of an item's Property Pages) to record the correct name of the code element.
* 
Note that if a model item has a CODE_GENERATION_NAME value set, ACS generates that value as the code element name.
The following example demonstrates how code elements with name clashes are reverse engineered. A class has three attributes named salary, Salary and SALARY:
public class Annual_Salary
{
public int salary;
public int Salary;
public int SALARY;
}
For salary, the Synchronizer creates an Attribute named salary - no value is set for the CODE_GENERATION_NAME property.
For Salary, there is a name clash so the Synchronizer creates an Attribute named Salary;1 - its CODE_GENERATION_NAME property is set to Salary.
For SALARY, there is again a name clash so the Synchronizer creates an Attribute named SALARY;2 - its CODE_GENERATION_NAME property is set to SALARY
When the Class is generated, the three Attributes are generated with the correct names.
Basic types
The Java Profile package contains the following Basic Types in the Java Basic Types package: boolean, byte, char, double, float, int, long and short.
When you reverse code that uses a basic type, the Synchronizer searches the model for a matching Basic Type to use. If the Synchronizer cannot find a Basic Type to use in the model, it creates a new Basic Type that is scoped directly to the model. You can move any new Basic Types to the Java Basic Types folder in the Java Profile package.
Creating class diagrams for reverse engineered packages and classes
After reverse engineering Java code, you can create Class Diagrams to show views of the items you have created in the Model.
You can create a Class Diagram and add items to that diagram by dragging those items to the diagram. Alternatively, you can add items to the diagram through the populate commands: right-click the diagram background, point to Populate, and then click the command for the item types you want to add.