An 18-Year Drought
In the world of programming languages, 18 years is more than an eternity—it’s a generational shift. Yet that’s precisely how long the industry waited for a truly new, pure dynamic language built specifically for the JVM. Since Clojure’s debut in 2007, innovation in dynamic languages on the Java platform had effectively stalled.
Python stabilized. Ruby reached maturity. JavaScript conquered the world. Python rose again—but on the JVM, the world’s most proven and resilient runtime, dynamic language innovation had long gone quiet. The industry had largely decided that static typing was the future, leaving dynamic languages as relics to be maintained, not advanced.
Kotlin reignited that spark—a welcome breath of fresh air on the JVM—but its focus remained mostly on static constructs and semantics.
A small team at Ortus Solutions disagreed. They wanted to end the 18-year drought. They wanted to prove that dynamic languages could be fresh, modern, and blazingly fast. And they wanted to do it in 24 months, with a mostly part-time team, and without a single dollar of venture capital.
They did it in 21 months.
This is the story of BoxLang—the first pure dynamic language built specifically for the JVM in 18 years—created by betting everything on professional open source, AI-first development, and nearly two decades of hard-won experience.
Part I: The Foundation
17 Years of Professional Open Source
Luis Majano was born in El Salvador and studied computer engineering at Florida International University in Miami. In 2006, he created ColdBox—the first conventions-based MVC framework for ColdFusion. Nineteen years later, it remains strong.
That same year, Majano founded Ortus Solutions on a simple principle: professional open source works.
Not “open source as marketing” or “open source until acquisition.” Real, sustainable, professional open source—built on biblical principles of stewardship, excellence, documentation, and service.
For 17 years, Ortus built frameworks, libraries, and tools while providing professional services. The company maintained a portfolio of over 350 open-source libraries across the Java, JavaScript, and ColdFusion ecosystems. From a Miami startup, Ortus has grown into a company of over 40 professionals, expanding its operations into El Salvador—Majano’s birthplace—and into Europe since 2022, where he now leads from Málaga, Spain.
Those 350+ libraries represented nearly two decades of learning what developers truly need, what patterns work in production, and which architectural decisions pay dividends years later. The company was about to bet everything on that accumulated wisdom.
The Crisis of Possibility
By 2023, Ortus faced a crisis. Not a financial one—the business was thriving. This was a crisis of possibility.
The team wanted to build CLI tools. They wanted to create desktop applications, deploy them to embedded systems, and utilize serverless solutions across multiple cloud providers. They wanted their 350+ libraries to run on Android, in the browser via WebAssembly—anywhere developers might need them.
But they couldn’t. They were constrained by vendor decisions beyond their control. The runtime they depended on couldn’t go where they needed to go. They had no control over the full stack—from source code to bytecode. Innovation was stifled.
And then there was the broader landscape: dynamic languages had stagnated on the JVM. Since Clojure’s emergence in 2007—18 years ago—no truly new, pure dynamic language has been built specifically for the Java platform and today’s problems and runtimes. The industry had moved on, convinced that static typing was the only path forward. Dynamic languages were often treated as legacy—maintained, perhaps, but not innovated upon.
The Ortus team disagreed. They believed dynamic languages had a vibrant future on the JVM. But belief wasn’t enough.
The Stakes
The stakes were high. Ortus had 17 years of work, 350+ libraries, a thriving community, and an entire company’s future on the line. They could stay constrained and accept the status quo, or they could bet everything on a radical idea: build a completely new dynamic language from scratch—the first in 18 years with just a handful of geo-distributed people, and it had to be done part-time, and in less than 24 months.
Part II: Project Jericho
The Audacious Plan
In early 2023, Ortus finally made the decision. They would design and build BoxLang—a modern, dynamic language for the JVM that could go anywhere, be more than just a language but also a framework, provide comprehensive documentation, world-class tooling, and revive innovation in the dynamic language space.
Here’s what they wouldn’t do: seek venture capital, take outside investment, pursue other projects, or compromise their professional open-source values for investor returns.
Here’s what they would do: stop company growth, reinvest every dollar into Project Jericho, and give themselves exactly 24 months to ship a production-ready 1.0 release, or abandon the project entirely.
Twenty-four months. Make it work or lose everything. No runway extensions. No pivots to please investors. No safety net.
Breaking Down the Walls
The project needed a code name. They called it Jericho.
The symbolism was deliberate. Like the ancient city whose walls fell after faithful persistence, the team needed to break down the walls of their predecessors—the constraints, the limitations, the frozen innovation. They needed to create something entirely new from the rubble of those walls.
Ortus Solutions operates on biblical principles. The company believes in faithful stewardship of the resources entrusted to it, in servant leadership, and in building things that genuinely serve its community.
Project Jericho embodied those principles. This wasn’t about ego or market domination. It was about faithful service to a developer community that deserved better options. It was about being good stewards of 17 years of accumulated knowledge by putting it to work in the service of something greater.
Part III: Architecture
August 2023: The Team Assembles in Málaga
Majano assembled the initial team of five in Málaga:
- Brad Wood – Senior Language Engineer & Architect
- Jon Clausen – Senior Language Engineer & Architect
- Two language engineers from a specialized language company will serve as consultants to help design the initial parsers.
August 2023 was the infancy of AI assistance in software development. The team had early access to Gemini and ChatGPT. They didn’t know it then, but AI would become as fundamental to their development process as the JVM itself.
They started with a clean slate but 17 years of experience. They analyzed every major static and dynamic language. They studied successes and, more importantly, failures. They examined where Groovy, ColdFusion, and open-source CFML engines had succeeded for over 20 years and where they had been hindered.
The mission was clear: break down the walls. Build something new. End the drought.
The BLAST: A Revolutionary Architecture
The team made their most revolutionary decision during this retreat: the multi-parser architecture.
They created what they lovingly call the BLAST—the BoxLang Abstract Syntax Tree. It’s a common intermediary layer that multiple source languages can compile to, which then compiles to JVM bytecode.
This solved their biggest challenge: how to build an entirely new language without abandoning 17 years of source code?
The answer: build a CFML parser that transpiles CFML to the BLAST, which then compiles to bytecode. Ortus’s entire catalog of over 300 libraries, written in CFML, could run on BoxLang. They’d have an instant ecosystem from day one. MVC Frameworks, Testing Frameworks, DI, AOP, BDD — you name it, all libraries will be available.
But the BLAST’s potential went far beyond CFML. They designed it to be the target for any language parser. Groovy to BLAST to bytecode. PHP to BLAST to bytecode. Even COBOL to BLAST to bytecode if someone wanted to write that parser.
The BLAST became their lingua franca—a way to bring multiple language communities into a shared, modern runtime while preserving their source code investments.
Multi-Runtime from Day One
BoxLang was designed to be multi-runtime from the start—one language, many deployment targets. The team knew they’d need a CLI runtime, a servlet runtime, and cloud-native runtimes, all sharing the same language core. This couldn’t be bolted on later; it had to be part of the DNA.
Every runtime in BoxLang follows a hierarchical model, where contexts build themselves up like an onion—discovering new capabilities based on where they run.
This dynamic layering is made possible by the JVM’s mature, modular foundation. Decades of classloading, threading, and memory innovation give BoxLang the freedom to adapt, extend, and deploy anywhere—without changing a single line of code.
Documentation from Day One
The BoxLang documentation began on day one. With a clear vision of the road ahead, the team structured the entire knowledge base early and automated processes to keep it continuously updated and version-aware—a living reflection of the platform itself. This is what made ColdBox the de facto enterprise MVC framework in CFML: its passion and dedication to excellence in documentation.
Event-Driven Core
From 17 years of building ColdBox, the team knew the power of event-driven architecture. ColdBox’s interceptor pattern had been wildly successful—allowing developers to hook into framework lifecycle events and extend behavior without modifying core code.
They brought that philosophy into BoxLang at the language level. Class compilation fires events. Function invocation fires events. Developers and language extenders can hook into these events, implementing before and after AOP advices without any bytecode manipulation or complex wiring.
The language itself is extensible through clean, understandable event hooks.
Modularity Core
Building on the success of ColdBox’s hierarchical modular services, the same approach was envisioned for BoxLang. This would keep the core extremely lightweight and tiny, pushing all innovation to modular packages that could be built by the team or any member of the community. Everything had to be extensible via modules, including global functions, components, events, parsers, and more.
The Dynamic Object Framework
To achieve seamless Java interoperability, the team created the Dynamic Object framework—one of BoxLang’s key innovations.
The Dynamic Object framework makes any Java class interact transparently with BoxLang’s dynamic typing system. It provides:
- Auto-casting: Automatic, intelligent type conversion
- Auto-boxing: Seamless handling of primitives and objects
- Type promotions: Smart type upgrades when needed
- Type contagion: Dynamic type propagation through operations
- Type inference: Intelligent type detection without explicit declarations
- Dynamic functions to specific Lambda Interfaces: Intelligent Lambda Interface proxies coming from typeless functions.
All of this is built on JDK 21’s invoke dynamic capabilities, avoiding reflection overhead while maintaining dynamic flexibility.
The result? Dynamic BoxLang classes can extend Java classes and implement Java interfaces. This isn’t just calling Java code—this is true interoperability. BoxLang code can inherit from Java’s type hierarchy and participate in Java’s object model.
Java’s performance and ecosystem with dynamic flexibility. Developers get the best of both worlds without compromise.
AI-First Design
From that first week in August, the team utilized AI as a design partner. They held design sessions with Gemini and ChatGPT, discussing potential service architectures, evaluating approaches, and validating their patterns against the collective knowledge encoded in these models.
This wasn’t about having AI write code for them. It was about utilizing AI to validate thinking, identify potential issues early, and explore design spaces more efficiently than manual analysis allowed.
Part IV: The Journey
December 2023: Turing Complete
By December, just four months in, the team had achieved their first major milestone: a Turing-complete language. They had a basic parser, a functional runtime, and enough language constructs to write real programs. Was it fast? Heck no! But hey, that if statement was beautiful.
The Dynamic Object framework was working. They could call Java code from BoxLang. Basic type conversions were functioning. They had a foundation.
January 2024: The Team Expands
In January 2024, the consultancy company finalized its tenure; it was now up to Ortus. The foundation was solidly established, and it was time for the transition to the broader Ortus team.
The company added a significant portion of its engineering talent to Project Jericho:
Core Engineering Team:
- Jacob Beers: The master mind behind the BoxLang IDE based on VSCode and the ASM Maestro!
- Jorge Reyes (COO, operational leadership)
- Eric Peterson, Grant Copley, Javier Quintero, Jaime Ramirez, Davis Vega (Senior Engineers)
- Alex Ventura, Abilio Posada, Daniel Garcia (Senior Engineers)
- Michael Borne (Senior Engineer & ORM Specialist)
- Alan Quintana, Esme Acevedo, Dan Card (Senior Engineers)
Supporting Roles:
- Cristobal Escobar (Business Development and Marketing)
- Maria Jose Herrera (Marketing)
- Jonathan Lainez (Design Team)
Most continued working part-time on BoxLang while maintaining client responsibilities. This constraint turned out to be an advantage. When you only have limited hours, you ruthlessly prioritize. There’s no time for gold-plating, no room for nice-to-haves that don’t serve the mission. Client work kept the team grounded in real-world needs.
Jacob Beers continued leading IDE development, ensuring that BoxLang’s tooling would be professional-grade from day -60.
Brad Wood immersed himself in ANTLR to attack all possible scenarios of CFML parsing and our new BoxLang vision parser.
Luis and Jon continued development of all the framework capabilities of the runtime.
February 2024: Full Java Interoperability
Two months later, Java interoperability was complete. Not basic—complete. Dynamic classes extending Java classes: working. Interface implementation from dynamic code: working. Auto-casting and type promotions: functional across the board.
This was a critical capability. Without full Java interoperability, BoxLang would have been isolated from the Java ecosystem. With it, they had access to decades of Java libraries and frameworks.
The Chicago Retreat: Innovation Under Pressure
In early 2024, during the Ortus team retreat in Chicago, the team sought to provide developers with an online platform to test BoxLang. They envisioned try.boxlang.io—a website where people could write code, execute it, evaluate the results, and experiment with the language without needing to install anything.
But how would they achieve it? The discussion began with uncertainty. How do you safely execute arbitrary user code? How do you scale it? How do you make it fast and responsive?
After just one hour of intense discussion, the AWS Lambda Runtime was born. By leveraging serverless architecture, they could provide isolated execution environments that scaled automatically and cost-effectively. Each code execution would run in its own Lambda function, providing security through isolation and scalability through AWS’s infrastructure.
What started as a feature request became a complete runtime implementation. Today, the AWS Lambda Runtime not only powers try.boxlang.io, enabling developers worldwide to experiment with BoxLang instantly, but it also provides a production-ready deployment target for serverless applications.
Innovation born from necessity, delivered in an hour, serving two purposes. It was characteristic of how the team worked throughout the project.
March 2024: The Runtime Explosion
March was intense. The team was building multiple runtimes simultaneously:
- CLI Runtime: For command-line applications and scripting
- MiniServer: A lightweight, standalone web server
- AWS Lambda Runtime: Born from the Chicago retreat, powering both try.boxlang.io and production serverless deployments
- CommandBox Servlet Runtime: Integration with Ortus’s Undertow-based engine
- JSR223 Runtime: For embedding BoxLang in Java applications
- Desktop Runtime: For building desktop applications
- LSP Runtime: The Language Server Protocol as a complete runtime
Jacob Beers was driving IDE development forward. The BoxLang LSP was taking shape as a runtime itself. The VSCode extension was becoming feature-complete.
The team also finalized the template language. The .bxm file format was ready. They had studied GSP, JSF, Blade, and CFML, taking the best ideas from each. The template language would have full access to the language, support components, and integrate seamlessly with BoxLang’s module system.
April 2024: Documentation and Three Ecosystems
https://boxlang.ortusbooks.com went live. The custom Claude model, trained on Ortus standards and the ANTLR grammar, generated consistent, comprehensive documentation for every language feature.
The team also completed the CFML Compat Module. This was their third ecosystem strategy: BoxLang native, Java interoperability, and CFML compatibility. Developers could choose their path.
May 2024: First Beta at Into The Box
At the annual Into The Box conference, Ortus released the first public beta. The performance wasn’t optimized yet—parsing was slow, execution had overhead. But it worked. The vision was a reality.
ColdBox, the 17-year-old framework, was running on BoxLang. Multiple runtimes were operational. The IDE was functional. The documentation was live. The CFML compatibility module was parsing real-world code. And try.boxlang.io was live, letting developers experiment online.
In just nine months, the team had gone from zero to a functional, multi-runtime language with professional tooling and three ecosystems.
The community response was electric. This was real. The walls were falling.
June-December 2024: AI-Amplified Refinement
The second half of 2024 was about refinement at scale. The team parsed client code continuously. Certification of all internal libraries and frameworks began. The commitment to release minor updates monthly started.
Ortus had made AI integration systematic:
Mandatory Code Reviews: GitHub Copilot code reviews are now compulsory for every pull request. Not optional, not nice-to-have—mandatory. Every piece of code got AI analysis for patterns, potential bugs, and optimization opportunities.
Integrated Development: VSCode Copilot integration became required for all developers. Real-time problem-solving, inline suggestions, and performance analysis as developers typed. AI assistance became as fundamental as the compiler.
Issue Management: For bug fixes and small updates, the team started assigning GitHub issues directly to Copilot. The AI would propose solutions, and developers would review, refine, and incorporate them. This freed engineers to focus on architecture and complex problems.
Documentation Engine: Mid-2024 brought the real game-changer with Claude. The team trained a custom Claude model on Ortus’s coding standards—the Ortus style guides for both CFML and Java, as well as their architectural patterns and even their ANTLR grammar. This model kept BoxLang.ortusbooks.com synchronized with code changes, maintaining consistency across thousands of pages.
Without AI, the team would not have been able to achieve this in 21 months, despite having mostly part-time developers. AI didn’t write BoxLang—the team’s experience and expertise guided every major decision. However, AI amplified capabilities, enabling a small part-time team to achieve what would have required a much larger, full-time organization.
The full Ortus company, comprising over 40 people, was now engaged. While the core engineering team focused on language features, the entire organization contributed to testing, documentation, community support, client work, and infrastructure development.
February 2025: Tooling Maximized
Sixty days before the planned release, the tooling was ready. The IDE had all the planned features. The LSP was fully functional. Debugging capabilities were professional-grade.
The team had achieved what they set out to do: tooling first, not tooling later. Jacob Beers’s leadership on IDE development ensured that BoxLang would have professional tooling from day one:
- Deep syntax highlighting via custom tmLanguage grammars
- Context-aware code completion
- Real-time error detection
- Type inference and intelligent hints
- Line-by-line debugging with thread inspection
- Dynamic variable modification during debugging
- Professional debugging capabilities that many established dynamic languages still lack
April 2025: The Walls Fall
Twenty-one months after starting in Málaga, Ortus launched BoxLang 1.0, followed by 1.1 due to initial bugs discovered on the same day.
Three months early. Three months under their 24-month deadline.
They had built what took other languages 30 years to achieve in 21 months. They had created the first new pure dynamic language for the JVM in 18 years. And they had done it without a single dollar of venture capital, with a mostly part-time team, while still serving their clients.
The shofar had sounded. The walls had fallen. Something new had emerged from the rubble.
Project Jericho had arrived!
Part V: What Was Built
Nine Runtimes: Deploy Anywhere
BoxLang launched with nine production-ready runtimes, each solving real-world deployment needs:
- LSP Runtime: The Language Server Protocol as a complete runtime, powering IDE services
- Any OS (JVM): Runs anywhere Java runs—Windows, macOS, Linux, BSD
- Docker: Containerized deployments for CLI apps, MiniServer, and full servlet applications
- CommandBox: Ortus’s powerful Undertow-based servlet engine, 17 years in development
- WAR Deployments: Standard Java web archives for any servlet container
- Desktop: Native desktop application development
- AWS Lambda: Born from the Chicago retreat, powering both try.boxlang.io and production serverless applications
- JSR223: Embed BoxLang in any Java application as a scripting layer
- MiniServer: Lightweight standalone web server for microservices
Same language, nine different deployment targets. Write code once, deploy it anywhere—from embedded scripting to enterprise servers, from CLI tools to serverless functions, from desktop applications to containerized microservices.
This is “write once, run anywhere” for dynamic languages, finally realized in its fullest sense.
Three Ecosystems: Unprecedented Compatibility
BoxLang Native: Modern syntax, full OO capabilities with the Dynamic Object framework, the .bxm template language, event-driven architecture, and a growing module system. Everything fresh, modern, and fast—designed for today’s development challenges.
Java Ecosystem: Through 100% interoperability, BoxLang developers have instant access to the entire Java ecosystem. Maven Central, Spring Framework, Jakarta EE, Apache Commons—everything. The Dynamic Object framework ensures seamless interoperability—auto-casting and type promotions happen transparently.
CFML Compatibility: The CFML Compat Module provides a complete migration path for existing CFML applications. The CFML parser transpiles CFML source to the BLAST, which then compiles to bytecode.
All of Ortus’s libraries work across all three ecosystems. This is the largest initial ecosystem any new language has ever launched with—not because the team spent years building libraries, but because they built an architecture that could leverage existing code.
Why the JVM Was Essential
The Java Virtual Machine is 25+ years of continuous optimization. It has world-class garbage collection, sophisticated JIT compilation, and enterprise-grade performance characteristics. When you build on the JVM, you inherit decades of work by some of the world’s best virtual machine engineers.
Moreover, the JVM was the only mature platform for building a modern dynamic language with enterprise-grade performance. Its battle-tested production record, cross-platform nature, and massive ecosystem made it irreplaceable.
BoxLang was built on JDK 21, leveraging invoke dynamic for the Dynamic Object framework. By using invoke dynamic instead of reflection, BoxLang achieves dynamic typing performance that approaches that of statically-typed code—avoiding the performance penalties that many dynamic JVM languages suffer.
Part VI: The Formula for Success
What Made 21 Months Possible
Looking back, five factors made this possible:
17 Years of Experience: The team knew what worked because they’d built it before. They knew what to avoid because they’d hit those walls. BoxLang’s architecture reflects nearly two decades of framework development, library maintenance, and production debugging. When they designed the event system, they leveraged ColdBox’s proven interceptor pattern. When they built the module system, they avoided OSGi’s complexity based on real-world observations.
The Java Platform: The team inherited 25+ years of JVM optimization. They got enterprise performance without spending years building a runtime. They gained access to thousands of production-tested libraries. The JVM was the only mature platform that could support their ambitions for a high-performance dynamic language.
AI Integration: Systematic AI integration at every level—design, development, review, documentation—allowed a small team to achieve large-team output. Early access to Gemini and ChatGPT informed architectural decisions. Mandatory GitHub Copilot code reviews caught issues at scale. A custom-trained Claude model maintained documentation consistency. AI didn’t build BoxLang, but it amplified capabilities decisively.
Tooling First: By prioritizing developer experience and building professional tools before launch, the team ensured that developers would actually want to use BoxLang. Jacob Beers’s leadership on IDE development meant that 60 days before release, BoxLang had debugging capabilities and IDE features that some established dynamic languages still lack.
Financial Discipline: No VC funding meant no distractions, no pivots for investors, no pressure to compromise the vision. The 24-month deadline forced ruthless prioritization. Part-time developers focused on what mattered because they had to. Client work kept the team grounded in real-world needs.
Part VII: What’s Next
BoxLang 2.0 and Beyond
Ortus isn’t stopping. BoxLang 2.0 is already in development, with continued JVM optimization, enhanced language features, and an expanding standard library. The team is building a new module to support client and migration needs and focusing on being able to run their entire catalog natively in BoxLang.
The team is also building additional runtimes:
- Electron-based desktop: For web-technology-based desktop apps
- JavaFX-based desktop: For native desktop applications
- Azure Web Functions: Microsoft cloud integration
- Google Cloud Functions: GCP serverless support
- Android Runtime: Mobile app development
- WebAssembly: Browser-based execution
Every runtime they add expands the possibilities for BoxLang and what developers can build with it.
AI-First Development
Ortus launched the BoxLang AI Module in 2024, providing comprehensive AI capabilities with so much more coming soon:
- Encapsulation and abstractions for all major LLMs (OpenAI, Anthropic, Google, and more)
- Local LLM support included
- Memory management for conversational AI
- Chat interfaces and multi-turn dialogues
- Embedding support and vector storage
- RAG (Retrieval Augmented Generation) frameworks
- Agent construction tooling
The API design is fluent and dynamic—building AI agents with BoxLang is remarkably straightforward. An AI-first language with AI-first tooling, enabling developers to build AI applications with minimal friction.
The Complete Package
BoxLang isn’t just a scripting language. It’s a complete platform:
- Full scripting capabilities for any platform
- Complete OO with dynamic classes extending Java classes and implementing Java interfaces
- A modern template language influenced by the best ideas from GSP, JSF, Blade, and CFML
- The Dynamic Object framework enabling transparent Java interoperability
- Nine deployment runtimes covering everything from embedded scripting to enterprise servers
- Three complete ecosystems: native BoxLang, full Java access, and CFML compatibility
- Professional IDE and debugging tools from day one
- AI-first development tooling including a comprehensive AI module
- Full framework capabilities: events, scheduled tasks, box futures, security, PDF, Image manipulation, encryption, and so much more.
Ortus didn’t build a toy language for enthusiasts. They built a professional platform to continue servicing their clients needs and moving the JVM forward.
Epilogue: The Shofar Sounds
The BoxLang logo—a shofar—represents more than just branding. It represents the signal that the battle has begun, that the walls are falling, that something new is emerging.
For 18 years, those walls stood. Dynamic language innovation on the JVM was frozen. Developers were told the future was static, that dynamic languages were legacy.
The shofar has sounded. The walls have fallen. The 18-year drought is over.
BoxLang is here, built on biblical principles of faithful stewardship and servant leadership. It’s here because a company was willing to bet everything on serving its community well. It’s here because a small team believed that dynamic languages deserved better, and they were willing to march around those walls until they fell.
From an hour-long discussion in Chicago that gave birth to a serverless runtime, to https://try.boxlang.io enabling developers worldwide to experiment instantly, to nine runtimes and three ecosystems launching in just 21 months—BoxLang represents what’s possible when experience, platform, AI, and discipline align with a clear mission. All in a single JVM platform that unifies the entire world.
The dynamic renaissance has begun. And it’s only getting started.
BoxLang is professionally maintained by Ortus Solutions. Documentation, downloads, and community resources are available at boxlang.io and boxlang.ortusbooks.com. The language is open source, with professional subscriptions, and welcomes community contributions.
Luis Majano leads BoxLang development from Málaga, Spain, where he directs Ortus Solutions’ worldwide operations. The broader Ortus team continues to expand BoxLang’s capabilities and support the growing community.
