Project

General

Profile

Wiki » Frequently Asked Questions »

Runtime Technology

Is FWD a Java-based interpreter for Progress 4GL source code?

No.

The ABL source code is converted to Java source code. That code is compiled into a Java application that is a drop-in replacement for the original Progress ABL source. At runtime, neither the Java source code nor the Progress source code is needed.

In fact, this represents a move away from an interpreted environment (OpenEdge) to a very sophisticated compiled environment. Due to Just In Time (JIT) compilers and technology like Sun's HotSpot compilers, the Java Virtual Machine (JVM) in which the resulting code runs is able to generate native hardware instructions for all of the code (at runtime). This means that much of the resulting code often runs as fast as code generated by C/C++ compilers.

Does the result rely upon an interpreter?

No.

The result of the conversion is Java source code that is then compiled and executed. This code relies upon a Java Virtual Machine (JVM) to execute. However, it is important to note that a JVM is not an interpreted environment.

Does the result rely upon a runtime?

Yes.

The objective of the conversion approach is to provide a Java application that is identical in behavior and function (including the look and feel of the user interface) to the original application. Since the Progress ABL environment has highly diverse and complex functionality, it is neither practical nor desirable to generate all the code that would be necessary (for compatibility) directly into the application itself. Rather, it is attractive to minimize the generated code to that necessary to duplicate the application's behavior. Behavior that is common between applications (that which is provided by the Progress ABL runtime) naturally lends itself to being replaced by common code.

The FWD runtime encodes the logic to provide a set of functionality that is compatible with the behavior and function of the Progress ABL. For each feature of the Progress ABL, the runtime has been carefully crafted to match that behavior, however the actual API and implementation are pure Java in every way. Java's object oriented nature is leveraged to implement the runtime in a clean, modern manner. The implementation looks nothing like the code in the Progress ABL runtime. Even the API itself is very, very different.

There are some similarities in naming between the ABL and the FWD runtime framework. For example, each Java frame has a display() method that is invoked to copy data to the screen widgets and force the equivalent of a VIEW. The behavior or semantics of how it works is compatible. Otherwise there is nothing in common between the Progress ABL runtime and the FWD runtime.

How does the runtime work?

See Runtime Architecture.

What ABL language features are supported?

See Supported ABL Features.

What ABL language features are not yet supported?

See Not Yet Supported ABL Features.

What happens if a conversion project has ABL code that uses features that are not yet supported?

Here is what to do (in precedence order):

1. Sometimes the usage is in code that is dead or otherwise unused. In this case, remove the code from the project.

2. Very often it is possible to work around this usage, with other features that are supported. If there are few references to that unsupported feature, then the easiest path can be to manually change the ABL code to avoid that feature.

3. Add the feature to FWD. Code contributions are welcome. If your organization is not in a position to do the development, Golden Code will do it for you on a fee basis.

At this point there is no unimplemented feature that is too hard to implement or for which there is any doubt about whether the feature can be implemented. The scope of the remaining unsupported features is modest. All the very hardest problems have been solved already and all the largest features are implemented. While there are some features that may take months to implement, the effort is quite incremental. Compared to the effort that has been expended to achieve the current feature set, there is very little left to do.

The FWD project is committed to implementing the complete feature set over time.

Is the result pure Java?

Yes.

All of the converted code is pure Java. The converted code does depend on the FWD runtime (the classes in the compatibility framework). Although the FWD runtime itself does use a JNI library, the converted code has no direct dependencies on JNI.

To the extent that platform-specific features of Progress ABL were in use in the original application, these dependencies will continue to exist post-conversion. For example, launching external processes through OS-COMMAND is often hard coded to a given platform. Such code will be invoked by generated code that is pure Java, but the platform dependency will not have been removed. It will still work because we have implemented the support in the Java compatibility framework (and sometimes in a native library that the framework uses).

Is the result portable?

Yes, it is at least as portable as it used to be.

Since Java runs on a significantly larger number of platforms than does OpenEdge, it is fair to say that the result is more portable that the original application.

To the extent that platform-specific features of Progress ABL were in use in the original application, these dependencies will continue to exist post-conversion. For example, launching external processes through OS-COMMAND is often hard coded to a given platform. Such code will be invoked by generated code that is pure Java, but the platform dependency will not have been removed.

As part of a conversion project, the standard reports can be used to identify these dependencies and you can then work to remove them from the application when possible.

For these platform-specific dependencies (which cannot be removed) to work, you must ensure:

1. That the FWD JNI library has been ported to your target platform (currently Linux, UNIX and Windows are supported).
2. Your application-specific dependencies (e.g. scripts, external executable programs, shared libraries/DLLs, file system permissions...) are supported and properly setup/configured on your target system.

The effort to port the JNI library is typically a 4-6 weeks, so long as the target platform supports all the features needed. Contact Golden Code if you need help with this.

Is the runtime portable?

FWD Code

99.99% of the FWD runtime is written in pure Java and has no platform dependencies at all.

The remaining .01% is a JNI (native) library used for client support only. That library needs to be ported to each platform on which you will run the Java FWD client. Currently a port exists for Linux, UNIX and Windows.

ABL features that use the native library:

  • Child process launching relies upon pseudo-terminal support which is not provided by the standard Java process launching interfaces.
  • ChUI terminal support (e.g. NCURSES on Linux/UNIX, WIN32 Console on Windows).
  • MEMPTR support (direct access to memory).
  • Reading/writing environment variables.
  • Registry access on Windows.
  • Native API calls (e.g. PROCEDURE EXTERNAL) to load and call shared libraries/DLLs.
  • Some filesystem metadata which cannot be accessed directly from Java.

There is also a small "spawner" executable on each platform that is used to securely launch processes like the Java equivalent to appserver agents. This code is supported on Linux/UNIX and Windows. It also would have to be ported.

The effort to port the JNI library is typically a 4-6 weeks, so long as the target platform supports all the features needed. The spawner is typically another 1-2 weeks. If you have a platform that is UNIX-like, then the effort to port is much less. Contact Golden Code if you need help with this.

Of course, a prerequisite is that you must have the toolchain available (C compiler, make and other "binutils") on the given platform.

Software Dependencies with Native Code

When porting FWD to a new platform, one must also plan to support the dependencies that have native code:

  • JDK 8 that is fully compatible
  • PostgreSQL database server and utilities
  • PL/Java (enables user-defined functions written in Java to be processed in the PostgreSQL database server)
  • LIBFFI (used for native library API call support from ABL, see #1634)
  • NCURSES (or equivalent) for ChUI/TTY support (hardware ASCII terminals or emulated ASCII terminals)

Please see Software Dependencies for more details.

What relational databases can be used?

The converted application relies upon Hibernate and JDBC for its database access. Hibernate handles some of the differences in SQL dialects and any deviations are otherwise handled inside the persistence portion of the Java based runtime. This means that the runtime does require changes in order to support each new database.

At this time, the runtime supports the following databases:

  • PostgreSQL
  • SQLServer
  • H2 (as a standalone server and also using in-memory mode)

If you need a different database, any database supported by Hibernate can potentially be used as long as it also has all of the required functionality for the converted application. For example, for most applications PostgreSQL would handle all requirements, but if the application relied upon programmatically changed collation tables, then PostgreSQL would not be appropriate since its collation tables are hard coded at cluster installation.

Hibernate supports a long and growing list (30 or more) of databases. This includes all the major proprietary options (such as Oracle, UDB and SQLServer) as well as all the major open-source databases (such as MySQL and PostgreSQL).

Do NOT plan to use the Progress database with FWD. Although Hibernate does support Progress, the SQL implementation is not performant and there is no ability to execute Java-based user-defined functions in the database server itself. That means that performance on Progress DB would be poor.

The effort to implement this support would typically estimated at 3-4 months. Golden Code can help if needed.

Is there any database specific dependency in the resulting source code?

No.

The result was designed to be database agnostic. The same converted application code will work with multiple databases. This means that the database choice is one that can be made at the time that the application is deployed (on an database instance by instance basis). There is nothing compiled into the application that makes it specific to a given database. This means you can simultaneously use the converted application with the full range of supported databases.

Is the Java result really functionally identical to the Progress 4GL application?

Yes!

From an end-user perspective there is no difference.

This fidelity extends far beyond the UI to all aspects of the system. Reports, output files, database updates, business logic... everything has been made compatible.

What are the system hardware requirements?

See Hardware Requirements.

What are the system software requirements?

Please see Software Dependencies.

On which hardware and operating system combinations does the result run?

See Supported Platforms.

© 2004-2017 Golden Code Development Corporation. ALL RIGHTS RESERVED.