Genero or Java? Choosing a future for an Informix 4GL application.
An Informix 4GL estate has three defensible futures : recompile it into Genero and keep writing 4GL with a vendor behind it, convert it into Java your team owns, or run the 4GL as itself on GraalVM inside a modern application server. Each is right for a different situation, and a vendor who pretends otherwise is selling to you rather than advising you. We make two of the three — so here is the comparison we would want to read if we were buying.
One honest axis decides it.
The market presents this as a choice of destination. The axis that actually decides it is what happens to the source, and what the application depends on after cut-over. Recompiling keeps the source in 4GL — in a modern, vendor-maintained dialect — and keeps a runtime and toolchain relationship for the life of the application. Converting moves the source to Java and ends that relationship. Running on GraalVM keeps the source in 4GL and ends the relationship too, by making 4GL a language of an open execution platform. Price, risk and hiring all follow from that one axis.
Genero is a good answer when…
- Minimal application change is paramount. Genero BDL is a 4GL dialect built for exactly this move, and Four Js' own guidance is that simple recompilation works in many cases, with adjustments concentrated in the user interface — and their published description of that short path is a matter of weeks.
- Continued 4GL development is desirable — with a vendor behind it. The team keeps writing 4GL, in a maintained dialect, with commercial tooling, support and a roadmap. For a stable team that likes the language, that continuity has real value.
- A modernised interface matters more than platform independence. Genero renders one application across desktop, web and mobile clients, with presentation separated from the business logic — a mature answer to the terminal problem, delivered inside the 4GL world.
- A recurring runtime and toolchain dependency is acceptable. The estate exchanges its current vendor relationship for a healthier one, and accepts that the licence follows the application for as long as it lives. For some organisations that is a reasonable trade, and it should be made knowingly.
4GL to Java is a good answer when…
- Eliminating the language and runtime dependency is strategic. After cut-over the application is Java source you hold, on a JDK the industry maintains. No runtime licence follows it, and nothing of ours sits in the execution path.
- Holding the codebase in the market’s language is the goal. The output is readable Java — same function names, same comments, same structure — written to be adopted as the source whenever the team chooses.
- Recruiting from the mainstream market matters. Java is what the available hiring pool writes. The application becomes something an ordinary hire can be productive on, with a debugger, tests and continuous integration from the first build.
- Modernisation continues after the migration. A JVM application can expose an API, feed a queue or sit behind a web front end whenever the business asks — the migration is a beginning, not a terminus.
- The screens must survive. Menus, forms, dialogs and reports carry across faithfully, so operators see no change on day one — and fidelity is proven byte for byte against your own 4GL binaries, not asserted.
Two ways to preserve 4GL, and the distinction that separates them.
Genero preserves 4GL by keeping it inside a 4GL product ecosystem. GraalVM preserves 4GL by making it a language of your application’s JVM runtime. Both keep the rules in the language that expresses them best ; they differ in what surrounds the language afterwards — a vendor’s toolchain and runtime in one case, the JVM platform your organisation already operates in the other. That one sentence is usually enough to decide which of the two an estate should be evaluating.
4GL on GraalVM is a good answer when…
- The language itself is not the problem. 4GL expresses business rules directly, its arithmetic is exact by declaration, and the people who know the rules write it fluently. None of that needs replacing.
- The business rules should remain in 4GL. The .4gl runs as itself — no generated code to review — as a peer language beside JavaScript and Python inside a modern application server, compiled to machine code once a routine is hot.
- The runtime, the platform and the interface are what need modernising. The proprietary runtime is replaced by an open JDK ; the terminal is replaced by a modern web application in front of the same rules ; and the rules execute inside the caller’s transaction, identity and connection pool.
The question to put to every vendor on this list — including us.
Whichever way the comparison leans, one test cuts through all of it : how is compatibility established for my application, and can I verify it before committing? Our answer is the assessment : the compiler and the differential test run on a representative slice of your own estate, output compared against your own 4GL binaries, and every construct that needs a human decision counted per program. Ask every candidate for the equivalent, and weigh the answers side by side. Fidelity should be measured, not promised — by anyone.
Trademarks, and the basis of this page.
Genero is a product of Four Js Development Tools, and Genero and related marks are trademarks of their respective owner. IBM and Informix are trademarks of International Business Machines Corporation. ifxtools is independent and not affiliated with, sponsored by or endorsed by either. References here describe the publicly stated capabilities of the products for comparison, are believed accurate at the time of writing, and use the names solely for identification. If you are evaluating Genero, evaluate it from Four Js’ own materials — this page exists to frame the decision, not to make it for you.