Develop in ABL and Deploy in Java


It is a common misperception that using the FWD technology would require one to shift all development to Java. Shifting some or all development to Java is certainly possible, but it is not the only use case for FWD.

Developers who love the ABL and wish to indefinitely continue writing ABL code, can do so with FWD. This is made possible by the characteristics of the conversion process:

  • The process is fully automated, there is NEVER any manual editing of the result needed to get a compilable and executable result.
  • The conversion runs as a non-interactive batch job and can be easily integrated in a larger build process.
  • An entire application can be converted in a batch.
  • The process is repeatable, allowing ABL code changes to be processed at any time.
  • In most cases, individual files or arbitrary sets of files can be converted on their own which is convenient for development and testing.

Since the FWD runtime fully enables a drop-in replacement of OpenEdge, one no longer has to pay for a license (or Progress maintenance fees) in order to continue developing in the ABL.

Over the long term, the elimination of vendor dependence on Progress may be even more strategically important than the reduction in costs.

There are many technology benefits that can be obtained by using FWD for deployment. Some of the most obvious:

  • Easily integrate/call Java code (custom code or 3rd party libraries) from OO ABL. Direct Java Access provides access to any technology that can run in a Java Virtual Machine, without requiring any Java development.
  • Entire ABL GUI applications can be run as a web UI without the need for a complete rewrite. Get to web in weeks or months instead of years.
  • Take advantage of many 4GL Enhancements that do not exist in OpenEdge. This includes 4GL syntax additions as well as enhanced runtime features.
  • Write multi-threaded 4GL code. This provides a better approach to scaling batch and server-side systems than can be achieved with the single threaded OpenEdge approach.
  • Easily call into converted ABL code from multiple languages including appserver-like calls from Javascript.
  • The server and client code is more portable than is currently possible with OpenEdge. And if there is a platform that is currently unsupported, support can be added at any time without needing permission.
  • The converted application is database independent. At deployment time, you choose from a range of industry standard relational databases such as PostgreSQL and SQLServer. No application changes are needed. This is superior to the Progress data server concept because the FWD compatibility layer makes all databases look like an OpenEdge database from the ABL code's perspective.
  • Leverage the wide range of support, monitoring, management and debugging tools that can be used on the converted application and at runtime. Even without shifting development to Java, there are many tools that can provide capabilities unavailable in OpenEdge.
  • Participate in improving the core FWD technology. FWD is open source. Join the community that is making the 4GL better.

At any point in the future, development of some or all of a given application can be shifted to Java. The decision can be made on as granular a level as a single file. Or the decision can be made for the entire project. The timing and decision is under the control of the developers. This decision will depend on many factors such as the skills of the development team, resource availability, the tools/libraries/frameworks needed and the productivity levels achieved.

Regardless of future Java development plans, it usually makes sense to continue developing in the ABL during the transition to and testing of the converted application. No development freeze is needed. Changes written to the application can be integrated into the conversion project as frequently as needed and then conversion can be re-run.

Once the converted application is in production, the development language decision is often based on the best place to make a change. Sometimes it is easiest to make a quick addition or edit to the ABL while other times it is easier to add or change Java code. For teams with both ABL and Java expertise, this can be useful.

Even after shifting development to Java, ABL developers have a significant advantage over Java developers when it comes to FWD. The FWD runtime is at its core a compatibility framework that accurately and extensively implements ABL functionality and features. ABL developers will immediately understand the conceptual basis and functionality of the FWD runtime, even when reading the converted Java code. Since the application is shifted to Java as a drop-in replacement, it is the same application as when run in OpenEdge. This means that the application domain knowledge of the ABL developers is just as valuable (perhaps more so) as it was when development was done in ABL.


Although FWD does support a wide range of ABL features (see Supported ABL Features), FWD is currently a sub-set of the features in OpenEdge. When writing code to run in FWD, clearly it is important to only use supported ABL features. The list of supported features is always expanding. Outside contributions are welcome in the project or Golden Code can be contracted to add needed features.

The parser and conversion process are not yet designed to give the same level of feedback as the Progress compiler. In most cases, a syntax issue with ABL code will be pretty obvious. It is possible that some syntax problems would be easier to identify in the OpenEdge compiler than in the current FWD version. It is expected that future development work will improve the usability of FWD in this regard.

For schema changes (to the permanent database schemata or to temp-table/work-table definitions in source code), the conversion process is not incremental. In almost all other cases, the conversion can be run on a single file (or an arbitrary set of files). In the case of schema changes, a single run of the conversion process for the entire application is required at this time. This restriction will be eliminated in the future.

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