Metadata and migrating from VisualAge for Java

When you make changes to a Java bean using the Visual Editor for Java, the source code is updated to reflect the changes. The source code changes are reflected in set methods that change property values. However, some information used by the Visual Editor for Java is not stored in properties because it is only required at design time. This includes the position of a Java bean on the free form surface.

To store this information so that the Visual Editor for Java can be reopened with the Java bean at the same position, it is placed in a comment on the line that declares the Java bean. The statement below shows a Java bean representing a JFrame that is positioned at 16,17.

private javax.swing.JFrame ivjJFrame = null; // @jve:visual-info
decl-index=0 visual-constraint="16,17"

The comment representing the position of a Java bean is not required, and if no comment is present then a default position is allocated when the Visual Editor for Java is opened. This only applies to top level Java beans that are not contained within another and does not affect the placement of components within a container. The location of components within a container is determined by the container's layout manager and the component's bounds or constraints.

In VisualAge for Java, the position of the top level Java beans (also referred to as free form parts) is not present in the source code. So, if you migrate a file that was written using VisualAge for Java's Visual Composition Editor (VCE), default positions are used. If you wish to keep the positional information, then you can obtain a migration utility that is loaded into VisualAge for Java. It allows you to regenerate your classes with the position stored in a comment format. To get the utility, download the latest VCE Code Generation/Export Wizard from www7.software.ibm.com/vad.nsf/data/document4293

This migration utility is available as a tempfix that can be installed using VAJava's FixManager Workspace > Tools > FixManager. The utility will allow you to migrate and export classes that have been developed using VisualAge for Java's VCE to a format suitable for the Visual Editor. After installing this patch you can select a menu item called VCE Code Generation/Export... from the context menu of projects, packages, or classes. Selecting this item will launch a wizard that allows you to regenerate the code for classes that have been previously saved with the VCE. The free form positions will be saved in the comment format used by the Visual Editor.

If you have connections, we recommend you first regenerate this code using the Event Handling's third option of the VCE code generation options (i.e. 'Use an inner class for each event') before running this utility. However, some classes will not be able to be converted to this style due to a bug in VisualAge for Java. In this case, you should convert to style 2. The wizard also gives you the option to export the classes to a directory once the code generation is complete. Note that the Visual Editor for Java events support will not parse the old VCE style 1 ('Do not use any inner classes') pattern. Notice how you can set the code generation styles 1, 2, and 3:
VCE pattern 1

VCE pattern 2

Since the VCE maintained its own model of the Java beans and their property values and relationships, it always regenerated the source in a top-down fashion from this model. Any modifications made by a user to the source were limited to pre-defined user code points in the source delimited by comments //user code begin {1} and //user code end. Also, to indicate that the methods for the Java beans would be regenerated each time code generation was performed, the line /* WARNING: THIS METHOD WILL BE REGENERATED. */ was added to the method comment. The migration utility has an option that will remove these VCE generated comments from the exported code (not the source code in VisualAge for Java), as they are no longer applicable when the code is used within Eclipse. However, once the comments for the user code points have been removed from the source, the user code cannot be used within VisualAge for Java. The reason is that the presence of these comments is what protects the user code from being overwritten.

The Visual Editor for Java does not use a persistent object model for its Java beans and their property values and relationships, and instead parses the source each time. For this reason, the comments for user code points and for specifying method regeneration no longer apply, and modifications can be made freely to the source code. If the modifications alter the source code structure so that the Visual Editor for Java can no longer recognize the structure of the Java beans, you may not see them in the Design view or the Java beans list. However, the source will not be altered to suit the editor's style, and your changes will be preserved.

Related concepts
Code generation
Source code patterns
Externalized strings
Style of generated source
Event handling

Related information
www7.software.ibm.com/vad.nsf/data/document4293

(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.