Your 4GL, registered as a language on the runtime modern Java already runs on.
GraalVM is an advanced JDK built on OpenJDK : the Graal optimising compiler, one heap, and Truffle, a framework for implementing languages on top of it. Informix 4GL is registered as a Truffle language alongside GraalJS and GraalPy — identifier 4gl, its own language implementation — which means a rule written in 1994 is compiled to native instructions by the same compiler that optimises your Java, in the same process, under the same tools.
A registered language, not a wrapper
The implementation declares itself to the runtime with an identifier and a name, exactly as the platform's other languages do. The runtime does not know or care that 4GL is older than it is.
Compiled by the same compiler as your Java
There is no second-class path. A hot 4GL routine goes through the same optimising compiler, with the same inlining and escape analysis, as the Java running beside it.
One process, one heap
4GL, Java, JavaScript and Python are peers in one context. Values cross between them without a socket, a serialisation format or a copy.
Operated like any JVM
Heap dumps, thread dumps, metrics, container limits, APM agents. Your operations team learns nothing new to run it.
What GraalVM is, in the terms a board paper needs.
GraalVM is Java. It is an OpenJDK-based JDK, developed as open source in the open, and it is downloadable and redistributable without a commercial agreement — the Community Edition is the build this runs on. You install it where you install a JDK today, and your existing Java applications run on it unchanged — it is an OpenJDK-based JDK with the Graal optimising compiler and the Truffle language framework added.
That compiler is the change. For twenty years the JVM's optimising compiler was written in C++ and understood one language. GraalVM's is written in Java — easier to evolve, and open to being pointed at more than Java — and it attaches through an interface that is itself part of standard Java, which is precisely why this is an evolution of the platform rather than a fork of it. On top sits Truffle, a framework for implementing other languages against that compiler.
The commercial significance is that language support stopped being a matter of writing a new virtual machine. A language implemented on Truffle inherits the compiler, the garbage collector, the tooling and the interoperability that took the JVM two decades to earn. That is why JavaScript, Python, Ruby, R and WebAssembly all run there as first-class citizens rather than as bundled interpreters.
It is also, in plain terms, the most modern thing in enterprise Java today — the runtime the ecosystem's newest frameworks target for compiled performance. An Informix estate arriving there is not being parked on a compatibility layer at the end of its life. It is arriving on the platform the rest of the industry is moving toward.
The stack, and the row your 4GL occupies in it
How a language becomes native here — the idea worth understanding.
Writing a language implementation used to mean writing a compiler back end : instruction selection, register allocation, a garbage collector. Truffle removes that work with one idea. You write an ordinary interpreter — a tree of nodes, each of which knows how to execute itself — and the framework turns that interpreter into a compiler for you.
The mechanism is partial evaluation. An interpreter is a program that takes two inputs : the program to run, and its data. Hold the first one fixed — this specific 4GL routine — and specialise the interpreter against it, and what remains is a program that takes only the data. That residual program is a compiler's worth of output, derived automatically. The interpreter dispatch, the node objects, the field loads : all of it constant-folds away, leaving the arithmetic and the control flow the routine actually performs.
What makes it fast rather than merely correct is that the specialisation happens after the routine has run for a while, so it can use what was observed rather than what was declared : runtime profiling lets the compiler specialise hot code against the types, branches and values actually seen, and deoptimise back to the interpreter if an assumption later stops holding. This is why a dynamic language on this platform can approach the speed of a statically compiled one — and why an old, simple, statically-shaped language like 4GL does particularly well.
From node tree to machine code, and the loop that keeps it honest
What the implementation actually uses — checkable, not decorative.
The claims above are platform capabilities. What matters commercially is whether this implementation uses them, and it does, visibly in the source.
The language registers itself with the runtime under the identifier
4gl and the name Informix 4GL — that
registration is what makes it a language on the platform rather than
a library that reads 4GL. Loops carry the annotation that tells the
partial evaluator to unroll them, so a FOR over a fixed
range becomes straight-line code. Calls into the runtime that must
not be compiled into the specialised body — the SQL session, the
report engine, terminal work — are marked as boundaries, which is how
a compiled routine stays a compiled routine instead of dragging the
whole runtime into its compilation unit.
And the deoptimisation machinery is used rather than avoided : values the compiler is allowed to treat as constant are marked as such, and when one changes, the code invalidates itself and is recompiled. A language implementation that never invalidates anything is one that never optimised aggressively in the first place.
The database is the clock, and it always was.
The performance question about any 4GL program is usually asked the wrong way round. These are business programs : they open cursors, fetch rows, take locks, commit transactions. Nearly all of the wall-clock time is spent waiting for Informix, and only a sliver of it inside the language. That was true under the original runtime and it is true here.
What changes is the sliver. The SQL is untouched — the same statements, against the same server, over a pooled connection — so the part that dominates behaves exactly as it does today. The loops, the arithmetic, the string handling and the report formatting that surround the SQL are compiled to machine code by the same compiler that optimises your Java. The interpreter that people worry about stops existing on the hot path.
So the realistic expectation is straightforward : a program bounded
by the database, precisely as it is now, with the computation around
the database faster than the original runtime made it. A nightly
batch that runs in forty minutes is not waiting on
FOR loops, and nothing here makes it wait on them.
What you would actually be adopting.
An estate deciding on this is not signing up to a proprietary runtime with a licence that follows the application. It is adopting a JDK — an open-source one, published as builds anyone can download, with the source developed in public. If the relationship with us ends tomorrow, the runtime underneath does not go anywhere, and neither does the ability to run what you have on it.
The practical starting points are graalvm.org/downloads for the distribution and the community builds if your platform team prefers to take them from the release archive. An architect who wants to see what "a language on this platform" means before talking to us can read the languages reference — the framework our 4GL implementation registers with is the one documented there, and it is the same one the platform's other languages use.
Two ways to keep a 4GL application alive. They are not variations of one idea.
| Terminal emulation in a browser | A registered language on GraalVM | |
|---|---|---|
| What runs | The original 4GL runtime, unchanged, with its screen output redirected | ✓ Your 4GL, compiled to native instructions by the platform's compiler |
| What the user gets | The same 80-column modal screens, drawn with web technology | ✓ Whatever interface you build — the terminal statements are not carried across |
| Execution | Interpreted by the vendor's runtime, outside your JVM | ✓ In your JVM, in your application server, in the request's own transaction |
| Integration with your Java | Across a process or protocol boundary — a screen to scrape or a socket to marshal | ✓ A method call in one heap. No boundary to marshal across |
| Tooling | The vendor's, specific to the product | ✓ The JVM's — the profilers, heap dumps and APM you already run |
| Licensing | A runtime licence follows the application for its life | ✓ The runtime is the JDK you already deploy |
| What it settles | The delivery channel | ✓ Where the business logic lives for the next twenty years |
Why a CIO should care that it is this platform and not another.
It removes the succession risk without discarding the asset. The rules stay in the language that expresses them best and the people who understand them keep working in it, while every new engineer you hire works in Java, JavaScript or Python against the same data, in the same process. You stop needing to find 4GL developers in order to keep building.
It ends the runtime dependency. The execution platform becomes a JDK — the one your organisation already deploys, patches and pays for as part of its estate. There is no separate runtime whose licence follows the application, and no vendor whose roadmap decides when your application can move.
It puts the estate on the industry's direction of travel. This is where enterprise Java is going for compiled performance and multi-language execution. An Informix application that arrives here is on the same runtime as the newest thing your teams are building — not on a bridge that has to be maintained until it is eventually replaced again.
And it makes the business logic reachable. Once a pricing rule is a callable routine in a JVM rather than a screen in a terminal session, it can answer an API, a scheduled job, a message queue or another language directly. That is usually the capability the business was actually asking for when it asked for a web interface.
What you would be depending on.
The nature of the dependency, what it does and does not oblige the rest of the estate to do, and why this is engineering rather than research.
Is GraalVM open source, and what exactly would we be depending on?
It is open source, built in the open, and it is a JDK — an OpenJDK-based one, so it is Java rather than something adjacent to Java. GraalVM Community Edition is freely downloadable and freely redistributable, and that is the build this runs on. The dependency you take on is a JDK, which is a decision your organisation already knows how to make and already makes every year. Downloads are at graalvm.org/downloads, and the community builds are published at github.com/graalvm/graalvm-ce-builds.
Do we have to move our Java applications to GraalVM as well?
No. It is a JDK, and Java applications run on it unchanged — that is the point of it being a JDK rather than a new virtual machine. Whether other applications also move is a separate decision you can take on its own merits, later or never.
If the platform can compile any language, what stops this being a science project?
The parts that are genuinely hard — the compiler, the garbage collector, the interoperability — are the platform's, maintained by the people who maintain the JVM. What is ours is the 4GL semantics, and those are shared with the migration compiler rather than written twice : one runtime, one SQL binder, and the two backends held to the same output on the same programs. The novel surface is much smaller than it looks.
What an architect asks before believing any of this.
Where the time actually goes in a business program, and what happens to the surface in front of it.
How fast is 4GL on it?
Fast enough that the language stops being the thing you think about. A 4GL business program spends nearly all of its wall-clock time in the database — SQL round trips, cursor fetches, locks, disk — and almost none of it in the language itself. That SQL is unchanged here : the same statements, against the same Informix server, over a pooled JDBC connection. What sits around the SQL, the loops and the arithmetic and the string handling, is compiled to machine code by the same compiler that optimises your Java, so the part that was interpreted stops being a factor at all. The realistic expectation is a program bounded by the database exactly as it is today, with the compute around it faster than the original 4GL runtime made it.
What happens to our forms and screens on this path?
They are replaced, and that is the purpose of the path rather than a limitation of it. The terminal statements are not carried across — they stop the program and name the line rather than pretending to work — because the point is to put a modern reactive web interface in front of the same business logic. The front end is built the way a current application is built, with data entry designed around how the work is actually done, and it calls the 4GL routines that already price the order and check the credit limit. If instead you want the existing screens to keep working exactly as operators know them, that is the Java conversion, where the full dialog and forms implementation lives. The two options answer different questions.