The same 4GL, running as itself on GraalVM.

Why a second way to run a program is worth having at all.

A migration compiler answers one question : what does this program become. It is the right question, and the Java it produces is the deliverable — reviewed, owned and maintained by hand from cut-over onward. Nothing on this page changes that.

But there is a second question that a compiler cannot answer, and it arrives much earlier : what does this program do, right now, against real data, before anybody has agreed to keep its translation. Historically the only way to answer it was to run the original binaries on the original box — which requires the licence, the terminal and the operating system that the estate is trying to leave behind.

Running the 4GL as itself on a modern JVM answers that question without any of them. The same source, the same catalogue, the same arithmetic ; a process a developer can start on a laptop, embed in a server, and point at a copy of production. The migration is then a decision taken with evidence, rather than a leap taken on a schedule.

How an interpreter becomes machine code.

Truffle is the framework GraalVM provides for implementing a language as a tree of executable nodes. A language author writes the nodes ; the runtime supplies what turns them into fast code. When a routine has been executed enough times to be worth optimising, the partial evaluator specialises the node tree against everything it now knows to be stable — types that have not changed, branches never taken, values that are effectively constant — and the compiler emits machine code for the result.

The practical consequence is that the interpreter loop disappears from the hot path. A 4GL FOR loop that accumulates a total is not, after warm-up, a walk over node objects : it is compiled code with the loop body inlined into it, produced by the same compiler that optimises Java on the same JVM. Optimisation is tiered — a first, cheaper tier for code that is merely warm, a second for code that dominates — and the tiers are observable per routine, named with the 4GL function and the line it came from.

This is what makes the approach different in kind from an emulator or a shell-out. 4GL is not being simulated by a program written in another language. It is a language on the platform, compiled by the platform's compiler, sharing the platform's heap and garbage collector with everything else in the process.

The arithmetic is the part nobody can afford to lose.

Business rules are arithmetic before they are anything else, and 4GL's arithmetic is not the arithmetic most languages give you by default. DECIMAL and MONEY carry a declared precision and scale, and every operation on them is exact within it. A rewrite that reaches for a binary floating-point type — the default numeric in most languages a modernisation would target — does not reproduce those rules ; it approximates them, and the error appears as cents that will not reconcile, months after go-live, in a period close.

Both backends resolve this the same way, because both call the same FglDecimal : arbitrary-precision arithmetic carrying the declared precision and scale, with the rounding 4GL specified rather than the rounding the hardware happens to do. The value that comes out of a 4GL expression running on GraalVM is the value that came out of it on Informix — and the same value the migrated Java produces, because there is one implementation underneath all three.

The architecture page sets out what that costs and why the compiler refuses the naive mapping, with the worked arithmetic beside it.

A guest in someone else's transaction.

Inside a server the connection is not the language's to open. The host already has one : pooled, transacted, audited, authenticated as the user whose request is being served. A language that opened its own would run outside that transaction, outside the pool, and as whatever user its own settings named — which is how a script becomes a hole in an access-control model that everything else in the estate respects.

So the connection is lent, through the standard scripting bindings, and three consequences follow deliberately. The engine opens none of its own. It never closes the one it is given — close() is disarmed on the borrowed connection, because closing a pooled connection mid-request would end the caller's transaction. And the catalogue that LIKE resolves against is read from that same connection, so a column's type is the type in the database the program will actually read, not one captured at build time from a database that has since moved on.

If no connection is lent and a script runs SQL, it stops at that statement and says how to lend one. It does not quietly find one elsewhere. For a language being introduced into an estate that already has a security model, refusing is the only safe default.

Testing a rule that runs on GraalVM, in the build you already have.

Both backends put 4GL under automated test, and it is worth being precise about how each does it, because they are not the same mechanism and the difference follows from what each one is for.

The Java backend drives screens : an in-memory terminal, keystrokes queued ahead of the run, assertions on what the dialog displayed. That is what you want for an order-entry program, and it is covered on the migration pages.

This backend has no screen, so it tests the thing it does have : the rules themselves, called directly. A 4GL program is reached through the standard Java scripting interface — the same one a server already uses for any other language it hosts — so a JUnit test evaluates it, captures its output through an ordinary writer rather than a terminal, and asserts on the result. Arguably it is the better unit test of a pricing rule, because it exercises the arithmetic without the screen that happened to be in front of it.

Errors behave the way the rest of your Java does : a failure inside the 4GL arrives as an ordinary scripting exception naming the 4GL line, so a red test points at a statement rather than at a stack you have to decode.

The strongest test available here is the two backends against each other.

The same 4GL source can be translated to Java and run as itself on GraalVM, which makes a test possible that no single implementation can offer : run the program both ways and compare the output line for line. Reports are compared byte for byte.

We hold our own backends to that on every build, and it is the shape we recommend to an estate mid-migration, because it answers the question that actually keeps people awake. Not "does the translation compile" — whether it still produces what the original produced. Two implementations of a language are two answers to what the language means, and the dangerous failure is never a crash ; it is both of them running and quietly disagreeing about a total.

The same technique compares either backend against the original Informix binaries, which is how a wave earns the right to go into production : the rules were not re-specified, and there is a test that says so on every build rather than a memory of a testing week.

What the GraalVM backend does not do, stated plainly.

It has no screen. There is no terminal to own when a program is reached from a debugger or from another language, so the statements that need one — OPEN FORM, MENU, INPUT, CONSTRUCT, DISPLAY ARRAY and their neighbours — stop the program and name the file and line. They are refused rather than skipped, and the difference matters : a MENU that quietly did nothing would not run the program without its menu, it would run a different program, leaving every variable the dialog should have set unset and breaking later somewhere with no visible connection to the cause.

Loading a program prints what it will need before anything runs, so the answer arrives at load time rather than halfway through a batch. Several constructs are also not lowered yet and are refused the same way : arrays, dynamic SQL, report GROUP blocks and their aggregates, GOTO, LOCATE, FREE and any FETCH that is not forward.

Which of your programs this reaches is a question about your programs, not a general claim, and it is answered the same way every time : load them and read what comes back. A program that needs nothing on that list runs ; a program that needs something on it says so, by name and line, before it starts. That takes minutes on a directory of 4GL, and it is the first thing an assessment does.

Where this leads : 4GL as one language among several.

Once 4GL is a language on a polyglot runtime rather than a program compiled ahead of time, the interesting question stops being how to leave it and becomes where to keep it. A pricing rule refined over twenty years is not technical debt because of the language it is written in ; it is an asset written in a language whose runtime became a liability. Separating those two things is what this backend is for.

The Airtool platform is built on the same runtime family, with server-side JavaScript, Python and Groovy already running as peer languages under one supervised execution model — see airtool.io/platform and, for the Informix-specific route, airtool.io/modernisation/from-informix. A 4GL routine placed there is not a foreign body being tolerated : it is a language in the same context, in the same heap, under the same security and audit model as everything around it, with the screen it used to own replaced by a modern interface and the rule inside it untouched.

That is the direction, and it is deliberately the second step. The first is still a migration whose deliverable is Java you own — see build and package. What changes is that the estate is no longer choosing between keeping 4GL forever and losing it entirely.

The distinction worth holding on to is that the two backends on this page change how your code runs, and the platform changes what it runs inside — which is why it is a forward path rather than a third backend. The forward path sets the three side by side.

One place this already runs, if you would rather not assemble it yourself.

This page describes a language that embeds in a GraalVM host you provide. Building that host — connection pool, identity, audit, multi-tenancy and the operations around them — is substantial work in its own right, and usually not the work anyone set out to do.

An enterprise application platform already exists that runs GraalVM polyglot scripting as its execution model, with this 4GL wired in beside JavaScript, Python and Groovy as a peer language : a 4GL rule runs on the caller's connection, inside the same permission perimeter and audit trail as everything else, callable from the other three. That is the embedding above, already assembled and operated. Whether it is interesting depends on how far you mean to go, and the route is on the forward path.

The paper.

The execution model is written up in full — what GraalVM is and why a language implemented on it inherits a mature runtime rather than building one, how partial evaluation turns an ordinary interpreter into a compiler, a real compilation trace of a 4GL routine read line by line, deoptimisation and why it is what makes aggressive optimisation safe, the embedding contract and the host-lent connection, and the limits stated plainly.

Informix 4GL on GraalVM (PDF) — written for the architect deciding where the business rules should live.