Your Informix 4GL application can have another twenty years.
Modernise the platform. Preserve the application. Keep Informix, keep your business logic, remove the proprietary 4GL runtime — and move at your own pace, one program at a time, every step verified against your own binaries. Two paths serve it : readable Java your team owns, or the .4gl running as itself on GraalVM inside a modern application server.
The rules are the asset
Pricing, credit limits, despatch rules, period close. Both paths carry them across unchanged, with the arithmetic Informix defined — not re-specified, not reinterpreted, not rewritten by a team reading old code.
One front end, two executions
Compile the 4GL into Java your team reads and owns, or run the .4gl directly on GraalVM inside an application server. The language is understood once, by one compiler — and which way a program executes is a per-program decision, not a company-wide one.
Both arrive at an application server
Not a terminal in a browser frame. A JVM process inside your estate, with your connection pool, your transaction manager, your identity provider and your monitoring.
Informix stays where it is
No data migration, no schema rewrite, no second database to keep in step. The catalogue that the 4GL resolved against is the catalogue the migrated code resolves against.
What is actually worth preserving — and what is not.
Informix 4GL earned its place for reasons that have not expired. It
expresses business logic more directly than most languages that came
after it : a DECIMAL with a declared precision and scale
behaves the way an accountant expects, cursors and reports are part of
the language rather than a library bolted onto it, and a rule about
when to block a despatch reads in ten lines of 4GL what would take a
page of Java. For business arithmetic and data processing that is not
nostalgia — it is a genuinely good fit, and it is why these systems
have run correctly for thirty years.
What has expired is the platform underneath : a runtime licensed for the life of the application, a toolchain that narrows every year, and a hiring market that has become a search for specialists rather than an ordinary advertisement. That is what puts the continuity of the application at risk — and it is the part a compiler can fix without touching the rules, or the people who know them.
You do not migrate the company. You migrate one program at a time.
A migration is usually presented as one enormous project : everything old on one side, everything new on the other, and a single cut-over between them. This is not that. Both paths on this page run over one compiler front end — designed to implement the full Informix 4GL language, and held to that design by evidence rather than assertion : its behaviour is tested against the original Informix compiler, program by program, and its compatibility with your application is quantified on your own source — every construct that needs work reported and counted, never hidden — before a migration is committed. Because the language is understood once, the choice of execution is made per program, not per company.
So the estate moves the way an architect would actually plan it. The nightly settlement run takes one path while order entry takes the other. A subsystem crosses this quarter and the rest does not. Old and new coexist — for a transition, or indefinitely, if that is what serves the business — and a program that crossed can cross back, because the 4GL remains readable source throughout. What differs is what your organisation holds afterwards : a Java codebase in your repository, or 4GL running as a first-class language inside an enterprise application server.
One estate, two executions
Choose per program, not forever
4GL to Java — the codebase becomes yours
The migration : Java source in your repository, maintained by your team. Every module becomes readable Java — same function names, same comments, same structure — packaged as a Maven project with a versioned artifact your pipeline ships and rolls back. Screens, dialogs and reports carry across, so operators see no change on day one, and fidelity is proven byte for byte against your own 4GL binaries. The right path when the application must cross over as it is, screens included — and when holding the code in the market’s language is the goal.
Explore 4GL to Java →4GL on GraalVM — a language of the platform
The disruption : the .4gl runs as itself, inside a modern application server. No Java is generated and no build step intervenes. 4GL becomes a peer language beside JavaScript and Python — compiled to machine code by the platform once a routine is hot, executing inside the caller’s transaction, under the caller’s identity, on the connection pool the server already manages. The rules stay in the language that expresses them best ; the interface is rebuilt as a modern web application in front of them. The right path when the rules are correct and the terminal is the constraint.
Explore 4GL on GraalVM →Do not trust the migration. Prove it.
The real fear in any migration is not whether a compiler can parse 4GL. It is quieter than that : how do you know a calculation that has returned €37.12 for twenty years does not return €37.11 the day after cut-over? A defect like that does not crash, does not log and does not fail a smoke test. It is found weeks later, in a reconciliation, after the migrated system has been writing into the ledger.
So fidelity is measured, not promised. Every
migrated program can be run against the one implementation whose
correctness the business has been proving in production for decades —
your own 4GL binaries. Same inputs, same database, both
implementations, and the output compared byte for byte : arithmetic,
dates, NULL handling, cursors, screens and reports
alike. The verdict is binary — identical, or a defect. Ours to fix,
not yours to discover.
That standard holds on every build of the compiler, and it is the standard an assessment applies to a slice of your own source before a programme is committed. A percentage of automated conversion tells you how much typing was saved ; a byte-for-byte comparison against your own binaries tells you whether the business can rely on the answer.
Don’t trust the migration. Prove it.
Under the hood — a build step, or a language of the platform
On the Java path, what your team inherits is code it can read
A real business rule from the demonstration schema, and the compiler's verbatim output for it : the names, the comments, the SQL and the declared decimal arithmetic all survive. The GraalVM path generates nothing at all — there, the .4gl itself stays the program — so this is the artefact that exists only when you choose to own one.
FUNCTION check_credit_limit(cust_num, order_total, credit_limit)
DEFINE cust_num INTEGER,
order_total MONEY(10,2),
credit_limit MONEY(10,2),
owed MONEY(10,2)
-- Would this order put the customer
-- past their credit limit?
SELECT SUM(i.total_price) INTO owed
FROM orders o, items i
WHERE o.customer_num = cust_num
AND o.paid_date IS NULL
{ Note it is >, not >= : landing exactly
on the limit is allowed. }
IF owed + order_total > credit_limit THEN
RETURN "BLOCKED"
END IF
RETURN "OK"
END FUNCTION/**
* Translated from {@code FUNCTION check_credit_limit}.
* Source: {@code credit.4gl} line 9.
*/
public String check_credit_limit(Integer cust_num,
BigDecimal order_total$in, BigDecimal credit_limit$in) {
FglDecimal order_total = FglDecimal.money(10, 2).set(order_total$in);
FglDecimal credit_limit = FglDecimal.money(10, 2).set(credit_limit$in);
FglDecimal owed = FglDecimal.money(10, 2);
// Would this order put the customer
// past their credit limit?
fgl.query("""
SELECT SUM(i.total_price)
FROM orders o, items i
WHERE o.customer_num = ?
AND o.paid_date IS NULL
""", cust_num).into(owed);
...
}The declared MONEY(10,2) stays a declared decimal — no
floating point near money, ever — and the comment the author left in
1994 is still beside the statement it explains. The complete example,
with the NULL handling, the provenance Javadoc and the
reasoning behind every non-idiomatic choice, is on
Compiler
architecture.
The terminal is where the two paths honestly differ.
The one structural defect 4GL carries into the modern world is
coupling. The language was designed for the VT100 terminal, and its
user interface is not a layer over the code — it is written into the
code, statement by statement : MENU waits for a
keystroke, INPUT drives a form, and the screen travels
with the rules into any faithful translation. What an offer does
about that coupling is the honest way to compare offers, and the two
paths answer it differently, on purpose.
The Java path carries the terminal across, and treats that as a feature. Screens, menus and reports run exactly as they do today, so cut-over changes nothing an operator sees — and for high-volume keyed entry the character screen is still the fastest input method anybody has built, so keeping it is often right on its merits, not as a concession. Retire it screen by screen, years later, or never ; the rules do not care what sits in front of them.
The GraalVM path does not carry it, by design. Freed of the screen statements, 4GL becomes what it always was underneath — a server-side business-processing language — and the interface is rebuilt as a modern web application in front of the same rules. One decision, honestly stated : programs whose screens must survive take the Java path ; programs whose screens are the complaint take this one. The same estate routinely does both.
Every way out of Informix 4GL, and the one axis that decides it
The market presents this as a choice of destination — a newer 4GL, a browser, Java. The axis that actually decides it is what happens to the source and to its arithmetic : whether the rules are carried across, or re-derived by people reading old code — and whether a vendor sits between your team and your business rules after cut-over.
| Recompile into another 4GL | Rewrite in Java or Python | Carry the source across — this toolchain | |
|---|---|---|---|
| The source | ✕ Stays 4GL, in a vendor's own dialect | ✕ Discarded. The rules are re-derived from code that was never documented anywhere else — the highest-risk act in this field | ✓ Never re-specified. Translated mechanically into readable Java your team can adopt — or left as 4GL and run as itself on GraalVM |
| The business logic | – Preserved, but still locked to a proprietary language | ✕ Re-specified by a team reading old code, then re-tested from scratch — which is where these programmes overrun | ✓ Carried across mechanically ; nothing re-derived, nothing re-tested from a blank page |
| The arithmetic | ✓ Preserved — another 4GL is still a business language with declared decimals | ✕ Re-implemented in a general-purpose language with no business decimal by default : every calculation, rounding and comparison has to be found, mapped and verified case by case | ✓ Preserved as declared — DECIMAL and MONEY keep their precision, scale and rounding, proven byte for byte against your own 4GL binaries |
| The interface | – A rich client drawn by the vendor's runtime, driven by the same terminal-shaped program | – Rebuilt — usually the motivation, and the part that inflates the estimate | ✓ The Java path carries the screens, so operators see no change ; the GraalVM path rebuilds a modern web front end over the same rules |
| After cut-over | ✕ A runtime and toolchain licence, per seat or per server, for as long as the application lives | ✓ No runtime licence — after a multi-year programme, with reconciliation risk that surfaces in production | ✓ No runtime licence. Java source you hold, or 4GL on an open JDK — your choice, per program |
| Who can work on it | ✕ 4GL developers — now in a proprietary dialect with a smaller pool than the original | ✓ The general market | ✓ The general Java market — and 4GL stays writable for the people who know the rules |
| Principal risk | ✕ The same class of dependency under a new vendor : the clock resets rather than stops | ✕ Silent divergence : it runs, passes the smoke test, and disagrees with the original in the last cent, weeks later | – Translation fidelity — which is measured against your own binaries on every build, rather than asserted |
| Right when | – Disruption must be near zero and a recurring runtime cost is acceptable | – The estate is small, the rules are documented, or the system is being retired anyway | ✓ The rules are the asset, and re-deriving them is the risk the whole exercise exists to avoid |
Either way, 4GL stops being a proprietary language.
This is the part most often missed, and it changes what the decision feels like. 4GL source is text. What made it proprietary was never the text — it was that only one vendor’s compiler and runtime could execute it. Once a compiler you hold a perpetual licence to turns that text into Java — or executes it directly on GraalVM — the dependency is gone while the language remains perfectly usable, and changing your mind later costs nothing, because the 4GL remains readable source throughout.
Either way, no part of the running system phones home to a licence server — and the day-to-day workflow is covered on 4GL to Java.
Bought once, owned outright.
The commercial model is deliberately short. The licence is one payment, once, and perpetual — no charge per user, per session, per core or per CPU — and nothing the compiler produces is licensed, so the running application never depends on us. It comes in two forms : the standard licence, or a source code licence that delivers the compiler and the GraalVM execution engine as source, with full engineering support behind your own team — self-sufficiency as a deliverable, for organisations that require the toolchain under their own control. The model, the two forms side by side and the prices around them are set out on the business case, on one page ; the contractual instruments on the services page.
Engineering since the 1990s
ifxtools is a joint effort of Deister Software — building and operating enterprise ERP on IBM Informix since the 1990s — and Airtool Technologies, its engineering unit. The practice behind this compiler has run estates like yours for decades.
Proven in production first
Every capability here was used against production-shaped estates before it was offered to anyone — the same discipline that produced the extensions, the diagnostics and the compilers on this site.
A partner, not a dependency
Nothing we deliver requires a licence from us to keep running, and the toolchain itself is available under a source code licence with support behind your team. Who we are is on the company page.