A Clear Guide to Joget DX9: Features and What Changed From DX8

Most teams don't decide to run their apps on an aging platform. It just happens. You ship something on a version that works; it keeps working, and nobody wants to touch a stack that isn't visibly on fire. So you wait. Then one day, the Java runtime underneath is out of support, half your plugins won't load, and the thing you built to save time is now the reason releases drag on.

That's the quiet trap with low-code. And it's exactly the backdrop Joget DX9 walks into.

Here's the honest question worth sitting with: is DX9 a real step forward, or just a bigger version number stapled onto the same engine? Because those are very different things, and the answer changes whether you should care at all. The good news is that the jump to joget DX9 is more than cosmetic, and the gap between the old joget DX9 features and what came before is wider than most version bumps ever are.

First, what DX9 actually is, minus the marketing.

What Joget DX9 actually is

At its core, Joget is an open-source low-code platform for building apps and automating workflows without hand-coding every layer. You design forms, lists, and processes visually, and the platform wires the database and logic behind them. That part hasn't changed.

What changed is the engine under it. Joget DX9 is the biggest under-the-hood rebuild the platform has had, and that's the thing most people miss when they see the version number. The visual builder still looks familiar. 

The foundation it sits on was rewritten. If you're brand new to the platform and want the ground-level tour of forms, workflows, and how it all fits together, our primer on what Joget is covers that first.

Here's the shift that matters. Older versions leaned toward being a workflow tool with app-building bolted on. This release flips the weight. The Joget DX9 now points to running real enterprise applications at scale, not just routing approvals and forms. It's less "process engine that also builds apps" and more "application platform that also handles process."

That reframing is why the joget dx9 upgrade feels different in practice, and why a straight feature list undersells it.

The redesign matters most once you know what sitting still actually costs you.

The cost of standing still

Staying on an older release feels free. It isn't. The bill just arrives later, in pieces, and usually at the worst time.

Here's what quietly stacks up while you wait:

• Your runtime ages out of support. Old Java and framework versions stop getting security patches. You're now running production on foundations nobody upstream is maintaining.
• Plugins break on the namespace shift. The whole Java world moved from javax.* to jakarta.*. Any plugin built under the old naming scheme can stop loading, and in legacy versions, fixing that means rebuilding each one by hand.
• Performance hits a ceiling. Older architectures lean hard on the database for everything. As traffic and data grow, response times sag, and there's no easy lever left to pull.
• Migration debt compounds. Every month you delay, the gap between your version and the current one widens, and the eventual move gets bigger and scarier.

The longer you sit on legacy, the more the upgrade turns from a task into a project.

That's the real cost. Not one dramatic failure, but a slow tax on every release, every hire who has to learn a dead stack, every plugin that won't cooperate. This is exactly the pain joget dx9 was designed to remove, and the reason the newer joget dx9 features focus so heavily on the foundation instead of surface polish. Teams don't move to joget dx9 for a nicer button. They move because standing still got expensive.

DX9 was built to answer exactly this. Here's what changed.

DX8 to DX9: What actually changed

Most of the real work in this release happened below the surface. You won't spot it in a screenshot. You feel it in support timelines, in how the platform holds up under load, and in how much manual effort a plugin migration takes. Here's the side-by-side, so the jump from the old version to joget dx9 is concrete instead of hand-wavy.

Two of these punch above the rest. The move to Jakarta EE, Spring 6, and Hibernate 6 on Java 17 and 21 means you're back on supported, current foundations, so the security-patch clock resets in your favor. 

And that plugin row is the one I'd underline for anyone dreading the move: instead of rewriting every extension for the javax to jakarta shift, joget dx9 rewrites the bytecode itself at startup and stashes the original as backup. That single behavior removes what used to be the scariest part of upgrading.

The rest of the Joget DX9 features on this list- the in-memory grid, built-in Git, the performance tooling- are less about survival and more about running heavier workloads without flinching.

The table is the summary. A few of these deserve a closer look.

Joget DX9 features that matter

The table gives you the map. This is the walk-through. I'm skipping config knobs and staying on what each thing actually buys you.

• Automatic plugin migration. Old extensions built against the javax naming used to break. Now the platform rewrites the bytecode to jakarta at startup and keeps the original as a backup. Your existing plugins move without a manual rebuild, which is the single biggest reason the upgrade to joget dx9 stops being scary.
• Apache Ignite in-memory grid. Instead of hitting the database for every read, hot data sits in off-heap memory as a Hibernate second-level and query cache. Fewer round-trips, less garbage-collection churn, and response times that hold steady as load climbs.
• Built-in Git version control. Every save to an app, form, or process gets committed automatically. So you get a real audit trail and a clean way to roll back a bad change instead of praying you kept a copy.
• OSGi modular plugins. Extensions run as sandboxed, compiled bundles rather than interpreted scripts. They're isolated from each other and they run faster, which matters once you've got real logic in production.
• Native Performance Analyzer plus Glowroot. You can watch heap usage, connection pool activity, and slow queries in real time, right inside the UI. When something drags, you see the exact query or menu causing it instead of guessing.
• Enterprise clustering. The platform scales across multiple nodes with shared storage, so one box isn't your ceiling anymore.

Expert Tip: For production, compile your plugins natively against Java 17 and Jakarta rather than relying on the startup auto-transform. The automatic rewrite is great for getting moving, but native builds skip the initialization overhead and dodge edge cases with deep reflection.

Honestly, the version control piece is the one I'd sell hardest. Most low-code platforms treat change history as an afterthought, and among the Joget DX9 features, this is the one that quietly saves teams from their own mistakes.

Features explain the what. The why teams commit is more interesting.

Why teams choose Joget DX9

There's a belief that follows low-code everywhere it goes. It's fine for a leave request form or a small internal tool, but the moment you need real scale or real control, you'll outgrow it and end up rebuilding in proper code. Pick low-code, the thinking goes, and you're trading engineering depth for a bit of early speed.

I get why people believe it. Plenty of platforms earned that reputation by demoing beautifully and then choking the second traffic showed up.

But that story doesn't hold against what's actually under joget dx9. This is a Jakarta EE core with Spring 6 and Hibernate 6, an Apache Ignite in-memory grid for scale, compiled OSGi plugins instead of fragile scripts, clustering for high availability, and version control baked into every save. And when the visual builder can't express what you need, there's a full Java escape hatch waiting. That's not a toy tier. That's the kind of infrastructure you'd expect from something you wrote yourself.

So the trade-off most people assume just isn't the real choice here.

The point of joget dx9 isn't low-code instead of pro-code. It's low-code speed on the surface, with pro-code under the hood.

You build the ordinary 80% fast, clicking forms and flows together, and you drop into real Java for the hard 20% that actually needs it. The Joget DX9 features are arranged around exactly that split. Speed where you can afford it, depth where you can't.

That floor is also what separates it from the rest of the field.

How DX9 stacks up against other low-code platforms

Plenty of platforms can drag-and-drop a form. The differences show up later, in who owns the thing and how deep you can go when you hit a wall.

• Open-source and self-hostable. You can run joget dx9 on your own infrastructure, read the source, and keep your data where you want it. No black box, and no pricing model that charges you per app you dare to build.
• Real pro-code depth. Between OSGi plugins and a full Java layer, you're not boxed in by whatever the visual builder happens to support. Most rivals hand you a scripting sandbox and wish you luck.
• Enterprise infrastructure built in, not bolted on. The in-memory grid, clustering, and connection pooling ship as part of the platform. On a lot of tools, scale is an upsell or a plugin you bwith together yourself.
• Version control that's native. Every save is committed automatically. Compare that to platforms where "history" means a manual export and a folder named final_v2_actual.

That last one still surprises people. Change tracking is treated as core here, and it's a big part of why the joget dx9 features feel built for teams who ship for a living rather than hobby projects.

So the real question is whether it's time to move.

Already on DX8? Here's what the upgrade looks like

A lot of teams who come to us aren't choosing a platform. They're already on DX8 and wondering how painful the jump is. Honest answer: less painful than most major version moves, and Joget itself calls the path from DX7 and DX8 a streamlined one.

Here's what actually happens when you move to Joget DX9.

• Your apps, data, and processes carry over. The standard approach is to run the new version in a fresh folder that points to your existing database, since newer Tomcat and Java files are bundled. Back up first, always.
• Plugins migrate themselves. That javax to jakarta rewrite happens automatically at startup, so most extensions load without a manual rebuild.
• Check your custom Java and integrations. Anything doing deep, non-standard reflection or pinned to old Java is where you'll spend your testing time. Test in the new folder before you cut over.
• Enterprise license needs a quick re-request. The system key is tied to your server, so plan a license request around your migration date. Software Assurance subscribers get the upgrade at no extra cost.

The move to Joget DX9 is mostly copy, test, cut over. The risk lives in your customizations, not the platform.

So the last thing left to settle is whether the timing's right for you.

Should you move to DX9, and where to start

Short version: if you're on an older release and feeling the support clock tick, or you're picking a platform fresh and want room to grow, Joget DX9 earns a serious look. It suits teams building real applications, not just routing the odd approval.

The part that stops most upgrades is plugins, and that's the part that mostly takes care of itself now. The automatic bytecode migration moves your existing extensions without a hand rebuild, so the scary bit is smaller than it looks. Your data, forms, and processes come along too.

You don't have to do the move alone either. If you'd rather have a team handle the build or the migration, our Joget development services cover exactly that.

One honest caveat. This guide stays at the "what and why" level on purpose. The deep setup work, JVM tuning, Ignite configuration, clustering, and schema optimization deserve their own technical walkthrough, which we'll publish next and link here.