ColdFusion gets filed under "legacy tag-based scripting language" often enough that it's worth being precise about what actually runs underneath the tags. Since June 2002, every line of CFML anyone writes gets compiled to Java bytecode and executed on the Java Virtual Machine, the same runtime enterprise Java, Kotlin, and Scala code all share. That one architectural decision, made under a project codename almost nobody outside the CFML community remembers, is the reason ColdFusion in 2026 can still ship genuinely new language features, and it's the reason an entirely separate JVM language now exists specifically to inherit CFML's codebases. Neither of those things happens on the C-based interpreter ColdFusion started as.
The rewrite nobody outside the community remembers
ColdFusion 1.0 shipped in July 1995, written in Visual C++ and tightly coupled to Windows, with Allaire porting it to Solaris starting at version 3.1. That architecture had a ceiling: it tied the whole platform to whatever a small team could maintain in native code, on a shrinking set of operating systems, with no path to the object libraries the rest of the industry was already standardizing on. Before 2000, an Allaire architect named Edwin Smith, who went on to work on JRun and later the Flash Player, started a project internally codenamed "Neo" alongside colleagues Tom Harwood and Clement Wong: a complete rewrite of ColdFusion on top of the Java EE platform. It shipped publicly as ColdFusion MX 6.0.
That's not trivia. Every version since, MX 7 in 2005, ColdFusion 8 in 2007, 9 in 2009, 10 in 2012, all the way through ColdFusion 2025 in February 2025, has been an extension of that same Java-based architecture, not a second rewrite. CFML templates compile to .class files and run as ordinary Java bytecode. A ColdFusion component can extend a Java class, implement a Java interface, or get packaged as a WAR file and deployed into any servlet container that runs Java at all. ColdFusion 9 added ORM support in 2009 by wiring CFML directly into Hibernate, the same object-relational mapper a huge share of the Java world already used, instead of building a proprietary one from scratch. None of that is available to a platform that only knows how to talk to itself.
That containerized deployment path exists for the same underlying reason the Hibernate integration does: once the runtime is the JVM, ColdFusion inherits whatever the rest of the Java ecosystem already built for that runtime, rather than needing a bespoke equivalent maintained by a much smaller team. A WAR file built from a ColdFusion codebase deploys the same way a WAR file built from a Spring application does, into Tomcat, into a Docker image, into whatever orchestration layer a given shop already runs everything else on. That's the quiet, unglamorous payoff of the Neo rewrite: it didn't just make ColdFusion cross-platform in 2002, it made ColdFusion inherit the next twenty years of Java tooling by default, largely without Adobe having to build any of that tooling itself.
What that buys you in 2026, specifically
The clearest recent proof that the JVM boundary is still doing real work showed up in ColdFusion 2025 Update 8, a patch release that sounds routine on paper and turned out to add several pieces of genuinely new language ergonomics, more than one of them explicitly about that Java boundary. One of them lets a ColdFusion function be passed directly into a Java method that expects a "Single Abstract Method" functional interface, the same shape Java's own lambdas target.
“the runtime often adapts a CF function object to the SAM when you pass it into a Java method”
Ben Nadel, on functions-as-Java-operators in ColdFusion 2025.0.8, bennadel.com
Nadel's writeup walks through calling java.util.concurrent.atomic.AtomicInteger's updateAndGet() and accumulateAndGet() methods, passing a CFML closure directly where Java expects a lambda, with the closure keeping its lexical scope across that boundary. That's a small feature on its face, but it's the kind of small feature that only exists because someone at Adobe is still doing the unglamorous work of keeping CFML's function objects interoperable with wherever the JVM's own type system has moved, more than two decades after Neo shipped.
The same update let built-in functions, not just user-defined ones, be passed as callbacks, and added a genuine Set data structure to the language for the first time. Sets sound like a minor addition until you notice what developers were doing without them: building a struct, throwing every value in as a key with a throwaway true value, and calling .keyArray() to fake a set out of a hash. The new syntax removes that workaround outright, and it's exactly the kind of small ergonomic gap that only gets closed on a language someone is still actively maintaining.
“I do not think (that word) means what you think it means”
Ben Nadel, on ColdFusion's Sets documentation overstating support for complex values, bennadel.com
That line is worth including precisely because it isn't a puff piece. Nadel's testing found the new Sets implementation uses hash-based equivalence rather than reference identity, so two structurally identical but genuinely distinct objects get treated as duplicates, which isn't how a set behaves in JavaScript or most other languages that use the same name for the structure. Adobe's own documentation claims Sets support "any ColdFusion value" without qualifying that claim. That's a real, current example of ColdFusion shipping a real feature with a real rough edge, which is a more honest picture of where the language sits in 2026 than either "CFML is frozen in 1999" or "CFML is thriving" would suggest on its own.
The same update also let developers call member methods directly on struct, array, and string literals, and use bracket access directly on a method call's return value, chaining operations like .insert() or .append() without first assigning a throwaway variable purely so there'd be something to call a method on. That's a small syntax gap, but it's exactly the kind of gap that accumulates in a tag-based language built up over three decades, and closing it is ordinary language-maintenance work, not a headline feature. The fix has its own limit, and Nadel's writeup is specific about where it stops.
“you cannot call member methods on numbers”
Ben Nadel, on the parser ambiguity between decimal points and method calls, bennadel.com
That limitation isn't an oversight, it's a direct consequence of how CFML's own parser has to read a bare numeric literal: 3.toString() is genuinely ambiguous between a method call and a decimal point followed by a property-style token, and the parser resolves that ambiguity by disallowing the call rather than guessing. It's a small, specific example of a constraint the language has been carrying since long before Java entered the picture, still visible in a feature Adobe is shipping in 2026, sitting right next to features that only exist because of the JVM underneath. Old constraints and new capabilities showing up in the same patch release is a fair one-line summary of where CFML actually is right now.
Browse the ColdFusion reference →A second language, same JVM, same reason
The more consequential story isn't a single Adobe patch, it's what the CFML community outside Adobe has built on top of the same architectural bet. Ortus Solutions, the company behind the open-source ColdBox framework and CommandBox tooling, has spent recent years building BoxLang: a new, JVM-native scripting language whose parser explicitly supports both its own syntax and CFML directly, positioned as a modernization path for existing ColdFusion and Lucee codebases rather than a clean-slate replacement that discards them.
“The theme running through this release is control: control over how HTTP clients are created and reused, control over what happens when a request fails, control over how much data a response is allowed to buffer, control over when Java classpaths reload, and tighter alignment with CFML behavior.”
Ortus Solutions, on the BoxLang 1.16.0 release
BoxLang 1.16.0 shipped in early August 2026, closing 50 issues, and its own release notes list closer CFML compatibility as a stated engineering priority, not a marketing footnote. That priority only makes sense because BoxLang runs on the same JVM ColdFusion has run on since 2002; a codebase full of .cfc components and cfquery tags can, in principle, be pointed at a different runtime without a from-scratch rewrite, because the underlying execution model, bytecode on a JVM, hasn't actually changed underneath it. Ortus lists ColdFusion and CFML compatibility as one of the project's stated foundational pillars, not something bolted on after the fact.
ColdBox itself turned 20 in 2026, and ColdBox 8 specifically added native BoxLang support, meaning a framework CFML developers have used to structure applications since roughly 2006 now runs, largely unmodified, on the language built to eventually carry the ecosystem forward. The ecosystem around ColdBox has grown past 700 modules, and a companion BoxLang skills directory launched with more than 200 entries of its own. That's not the footprint of a community that quietly handed its future entirely to one vendor's roadmap. It's a community that looked at the same JVM foundation Allaire bet on in 2002, decided it was still the right foundation, and built a second, actively maintained language directly on top of it instead of waiting for Adobe to make that call alone.
Not every fix in that same update was about Java interop specifically. round() picked up an optional precision argument in 2025.0.8 as well, letting a call like round( 123.45678, 3 ) return a value rounded to three decimal places directly, instead of the workaround CFML developers had been writing for years: multiplying by 1000, rounding to the nearest integer, then dividing back down. Ben Nadel, who wrote up the change, called it himself a "super minor improvement," and he's not wrong to undersell it. It's included here precisely because it isn't dramatic.
“it simply truncates the decimal portion to the given number of decimal places; but it doesn't apply any other formatting”
Ben Nadel, on the new round() precision argument in ColdFusion 2025.0.8, bennadel.com
A function that's existed since the language's earliest versions getting a genuinely new, useful argument in 2026 is a small but real data point against the idea that CFML's core standard library stopped changing once the language's popularity peaked. Someone still has to decide that a workaround developers have been writing by hand for two decades is worth turning into a first-class parameter, and someone still has to ship it. That's ordinary language maintenance, the same kind every actively used language does, not the behavior of a platform that's only being kept on life support.
None of this means Adobe's ColdFusion product is going away, or that BoxLang has replaced it in any measurable sense yet. What it means is that the 2002 decision to rebuild on Java wasn't a one-time modernization event CFML then coasted on for two decades. It's the reason a patch release in 2026 can add genuine new language ergonomics tied directly to Java's own type system, and it's the reason a separate language, built by people who make their living in this ecosystem rather than by Adobe itself, exists as a real migration target instead of a hypothetical one.
Where this leaves you
- CFML has compiled to Java bytecode on the JVM since ColdFusion MX 6.0 in June 2002, not since some recent modernization effort; that's the architectural fact everything else here depends on.
- ColdFusion 2025 Update 8 shipped real new language features, functions as Java SAM operators, built-in functions as callbacks, a native Set type, tied specifically to that JVM foundation, alongside at least one documented rough edge (Set equivalence) that shows the work is genuinely ongoing, not finished.
- BoxLang, built by Ortus Solutions on the same JVM, treats CFML compatibility as a stated engineering pillar, and ColdBox 8 already runs on it natively, twenty years after ColdBox itself was first built for ColdFusion.
- None of this settles whether a given shop should stay on Adobe's ColdFusion, move to Lucee, or evaluate BoxLang, but any of those decisions get easier to make honestly once you know they're all variations on the same underlying JVM bet, not competing philosophies starting from scratch.