A few months ago, Berger Levrault’s research team published an article on the result of an experiment allowing a JAVA application to work together with a Visual Basic 6 application. This work showed that you could use business components developed in Visual Basic 6 from JAVA and even “run” an entire application without having to use its GUI.
The same team is delighted to announce that the same approach has been successfully reproduced but this time with the PowerBuilder language in its version 12.5. Even if this language is very different from VB6, the issues related to PowerBuilder are the same, especially in terms of operation: no web programming possible, no clear functional separation of the code and finally opacity of the real work of the compiler.

PowerBuilder is an integrated development environment owned by SAP since the acquisition of Sybase in 2010. On July 5, 2016, SAP and Appeon entered into an agreement whereby Appeon would be responsible for the development, sales, and support of PowerBuilder. Over the years PowerBuilder has been updated with new standards. In 2010, a major PowerBuilder upgrade was released to provide support for the Microsoft .NET Framework. Official support for 12.5.1 and earlier ended April 2013. PowerBuilder 12.5.2 ended August 31, 2015.

PowerBuilder has a native data management object called DataWindow, which can be used to create, modify, and view data from the database. This object gives the programmer several tools to specify and control the appearance and behavior of the user interface, and also provides easy access to database content.

PowerBuilder is an object-oriented programming language. Almost all visual and non-visual objects support inheritance, polymorphism, and encapsulation. The programmer can use a common code framework such as PowerBuilder Foundation Classes, also known as PFC, to inherit objects from pre-existing code and take advantage of it. PowerBuilder applications are typically compiled into p-code, which is then interpreted by the PowerBuilder runtime engine. Although it can be compiled into machine code, a typical business application does not run much faster except for CPU intensive calculations. The main reason that machine code compilation was not used is due to many errors in PowerBuilder, especially in machine code generation.
Language extensibility is rather limited for older versions of PowerBuilder. Powerbuilder provides to overcome this a C ++ extension called PBNI (PowerBuilder Native Interface). Developing a solution that includes external C ++ code entails the need not only for knowledgeable C ++ developers, but also for a PowerBuilder expert to guide the developer through the myriad of subtleties of the language and the virtual machine. PowerBuilder.
Inheritance and object-oriented functionality are limited to certain types of objects (Windows, user objects, and menus). Particularly, it is not possible to inherit from a DataWindow.

Interoperability, a matter of Native Code.

The way to exchange between two computer languages is to reduce their composition to the lowest possible level, in machine language, binary; then back up as needed to one or the other language.

In our case, the PowerBuilder extension “PBNI” (PowerBuilder Native Interface), inspired by Java Native Interface, will have provided part of the solution. In fact, this extension, supplied natively from PowerBuilder 11, allows to “embed” the PowerBuilder virtual machine (PBVM) in a C ++ application. With the immediate effect of being compiled in … machine language!

By making this C ++ application a classic Dynamic-Link Library (DLL), we solve the second problem, which is to expose the functions of our powerbuilder objects. In fact, the C ++ DLL accesses the Powerbuilder application and the objects that compose it, then the DLL itself exposes functions representing access to the entire powerbuilder application, and we use these functions to access from java the results of function calls corresponding to requests from the WEB client. This gateway is provided by JNA (Java Native Access), an overlay of JNI (Java Native Interface).

• The last issue is that of the target architecture, on the JAVA side. Indeed, several optics are possible:
  Representing fully what a Powerbuilder application is on the Java side makes it possible to consider programming new features using objects and methods from Powerbuilder in java classes. This also implies “weighing down” the target code with a significant volume of code that must disappear after the migration is completed.
• Represent only what is unique to a Powerbuilder application compared to another PowerBuilder application, this time on the C ++ DLL side offers the guarantee of fluidity and speed of execution, however this implies a significant opacity for the developers and a significant difficulty to code new features on the JAVA side. In this context, Java only accesses the functions (entry points) of the application and not the objects that compose it.

Both options guarantee the same access result whether it is to the runtime of an application (with its context) or to the business objects that compose it.

JNA is built and tested on macOS, Microsoft Windows, FreeBSD / OpenBSD, Solaris, GNU with Linux, AIX, Windows Mobile, and Android. It is also possible to modify and to recompile native build configurations to make it work on most other platforms that run Java. With Java and Java Native Access, we can replace the “Main” of a VB program (Context) by a Java Application that uses the COM Object (Dll) as a Business Logic code.

This approach has been tested and validated on a tool from the Healthcare suite of Berger Levraut solutions, it has shown the possibility of considering an iterative technological migration and the possibility of coding new functionalities in another language. Indeed, this approach guarantees regular and tested releases into production. In addition, it allows the immediate implementation of “modern” practice such as “Test Driven Management (TDD)” since the target languages ​​can implement from the start of our migration process the most effective frameworks in these areas.

Conclusion

After Visual Basic 6, Berger Levrault’s Migration and Architecture team shows again, but this time with PowerBuilder, that the oldest programming languages ​​and frameworks, unmaintained and without support from their editors; do not necessarily require a migration process with a total rewrite of the applications.
The Migration and Architecture department of the Research, Innovation and Technology Department of Berger Levrault here breaks the idea that one can have of a migration with a whole lapse of time with a complete rewrite of the application in a new language, and where it can only be deployed when it is almost completely recoded.

By offering a technical and architectural approach focused on the cross-cutting needs of customers, development teams and the company, BL is once again demonstrating its ability to offer innovative and effective solutions.