Migrating from version 7.0 and after

If you are migrating from a version earlier than version 7, you can use the EGL V7.0 migration tool to migrate directly to version 7.5.

Migrating from version 7.5 and later

To move from version 7.5 to version 8.0, you do not need to run a migration tool, but be aware of the following concerns:
  • The directory structure for projects has changed in version 8.

    With version 8.0, EGL places generated Java code into the new EGLGen/JavaSource directory at the top level of the project directory structure. EGL refreshes this code each time you generate, including when you click Project > Clean. Use the top-level JavaSource directory for Java code you have modified by hand; the Clean command does not touch this directory.

    For Rich UI projects, you no longer use a generation mode preference to determine whether you are generating for debug or for runtime use. Instead, both types of code are generated automatically into the EGLGen/JavaScript/Debug and EGLGen/JavaScript/Target directories.

    If you keep the version 7 directory structure, the project will work normally in version 8. If you update the directory structure to the new version 8 structure, you can no longer use the project in version 7.

    Because of this change, it is more likely for developers to create separate projects for Java™ generation that merge into a single deployed project. If these projects have cross-dependencies, you might need to change your Java build path. For more information, see Java build path.

  • Rational® Business Developer version 8 requires Java 5 or later; see "Java considerations in Rational Business Developer version 8" in this topic.
  • The EGL NUMBER loose type has a new internal representation when you generate for JavaScript. No action is necessary in most cases because the default behavior for EGL is to regenerate JavaScript automatically when the EGL files are initially brought into version 8. If you disabled the Generate after build preference for JavaScript, you must manually generate all JavaScript files that include the NUMBER type before using them in version 8. For more information, see Loose types and Setting generation preferences.
  • Best practice when moving to a new version is to create a new workspace.
  • If you use EGL Rich UI and do not update your widget libraries when you move to version 8, be aware of possible compatibility issues. For more information, see "Known compatibility in widget libraries" in this topic.

Java considerations in Rational Business Developer version 8

Version 8 requires Java 5 (also known as version 1.5.0) or later. This requirement is an upgrade from version 7, which required Java version 1.4.0. Version 8 includes a Java Runtime Environment (JRE) for Java 6. This JRE is fully compatible with code generated by previous versions of EGL, and you do not need to regenerate your existing EGL programs because of the new JRE.

While you use EGL, you can choose to run your Java batch programs, and the Tomcat server, in the JRE that was installed with the product. You might also choose to run those batch programs in any other Java 5 or higher JRE that you have installed on your system, except for the JRE for WebSphere® Application Server. That JRE is used exclusively with that product. You also need a JRE to run generated code that you deploy outside of EGL or WebSphere Application Server. You can choose any Java 5 or later JRE for this purpose.

In most cases, the change causes no problems. However, if you are committed to a corporate standard of Java 1.4, do not migrate to version 8.

Known compatibility in widget libraries

Best practice when moving Rich UI projects to version 8 is to update the widget libraries for those projects to the latest levels. For instructions on how to import these projects, see Importing product-supplied projects.

If you choose to use widget libraries from an older release, be aware that only certain combinations of libraries have been tested. The following table shows the versions of the widget libraries that are known to be compatible. Other combinations are possible, but not guaranteed to work efficiently together.

Table 1. Widget libraries known to be compatible
Product version Rich UI widgets Dojo widgets Dojo runtime
8.0 2.0.0 1.0.0 1.5
7.5.1.5 1.0.3 0.8.0* 1.4
7.5.1.4 1.0.2 0.7.1* 1.3.2
7.5.1.3 1.0.1 n/a n/a
7.5.1.2 and earlier 1.0.0 n/a n/a

* Not officially supported; distributed through the EGL Café.

Migrating from version 7.1, up to but not including version 7.5

When you start the product, all of the projects are checked to see if migration is needed. This check is also completed when you import a project or check a project out of a source code manager. If you must migrate, the workspace displays a message and you can then select the specific projects and resources to migrate.

To migrate from EGL version 7.1 to 7.5, the following code changes require some files or projects:
  • ExternalType function parameters require the in modifier.
  • The path to Apache .jar files has changed.
  • BIRT report files need ICU4J (International Components for Unicode for Java) support.

Migrating from version 7.0, up to but not including version 7.1

No program automates the migration from version 7.0 to version 7.1; in most cases, no migration is necessary. Migration is necessary in two cases:
  • If you use forms and you migrated to V7, you must change your code before you run V7.1. Because EGL version 7 does not support forms, most users with forms did not migrate to that version.
    To migrate forms from EGL V7 to V7.1, make the following changes:
    • Add the @ operator to all printFloatingArea and screenFloatingArea properties.
    • Place all of the @printFloatingArea complex properties for a form inside the new printFloatingAreas property.
    • Place all of the @screenFloatingArea complex properties for a form inside the new screenFloatingAreas property.
  • If you work with a web project that was generated for versions 7.0 to 7.0.0.3 and whose code runs in WebSphere Application Server and accesses web services on all platforms, you must change the project. If the project is to run on a server other than WebSphere Application Server, no change is necessary.
To migrate a web project that uses WebSphere Application Server from EGL V7.0 to V7.1:
  1. Switch the class loader for the WAR file in the associated EAR file to PARENT_FIRST:
    1. Double-click the projectNameEAR deployment descriptor that is found in the root of the web project, where projectName is the project name. This deployment descriptor is a J2EE deployment descriptor, not an EGL deployment descriptor.
    2. In the deployment descriptor editor, click the Deployment tab.
    3. At the bottom of the Deployment page, find the Application section.
    4. From the Applications list, select the WAR file that represents the web project.
    5. In the Classloader mode list, select PARENT_FIRST.
    6. Save and close the deployment descriptor.
  2. Open the Resource perspective and remove the following .jar files from projectName/WebContent/WEB-INF/lib:
    • axis.jar
    • commons-discovery-0.2.jar
    • commons-logging-1.0.4.jar
    • eglwsdl.jar
    • jaxrpc.jar
    • saaj.jar
    • wsdl4j-1.5.1.jar
  3. To ensure that the ServerType build descriptor option is set to the appropriate version of WebSphere Application Server, regenerate the project.

If you are migrating COBOL source or Rich UI projects, you might need to make more changes. For details, see “COBOL-to-EGL migration” and “Rich UI project migration.”


Feedback