Jmix Recap 2025 and Plans for 2026

Intro

Software development has always moved fast, and in H2 2025, the pace shifted again. With the rise of agentic programming, generating large parts of an application became dramatically easier and faster. What recently looked experimental is now reshaping everyday development practice.

We at Jmix started investing in AI-assisted development back in mid-2024. But for us, the interesting question was never just how to generate more code, screens, or boilerplate in less time. In enterprise software, speed is useful only when teams can trust the result.

That is the real tension behind the current wave of AI-driven development. Building the first version of something is getting cheaper, but taking responsibility for what happens next is not. Enterprise teams still need systems that are secure, maintainable, scalable, and understandable by the people who will support them under real delivery pressure. And that is exactly why the market conversation is changing. For years, development platforms competed on speed alone. Now that speed is becoming more accessible, the focus shifts toward confidence, ownership, and control.

That shift makes the role of Jmix clearer. We do not see AI as a replacement for engineering discipline. We see it as a force multiplier that works best when combined with a structured platform for enterprise development. In other words, the opportunity is not just to build faster, but to build faster without giving up responsibility for the result.

In this article, we look back at what changed for Jmix in 2025 and how it shapes our product direction for 2026.

Jmix Recap 2025

Product progress in 2025 was not concentrated in one big headline release. It was spread across several areas that matter in real projects: platform improvements, more realistic business application examples, new architectural patterns for larger systems, and broader knowledge sharing with the community. Taken together, these changes made Jmix easier to adopt, easier to evaluate, and easier to apply in enterprise development practice.

Platform progress

The 2025 roadmap focused on five areas: onboarding, developer productivity, UI capabilities, business add-ons, and new development workflows. Across Jmix 2.5, Jmix 2.6, and Jmix 2.7, the product moved forward in all of them.

Overall, 2025 confirmed the same direction that was set in the previous recap. Jmix kept improving onboarding, daily development experience, enterprise UI, and business application support, while adapting its development workflow strategy to the realities of the AI era.

Real business application scenarios

In 2025, Jmix became easier to evaluate through concrete business applications, not just through framework features. The strongest example is the new open-source B2B CRM sample. It reflects one of the most familiar and widely needed use cases for Jmix: a business application that brings together customers, contacts, orders, invoicing, payments, tasks, and analytics in one system. That is exactly why it works well as a reference application. Teams can immediately understand the requirements, inspect the implementation, and see how far Jmix can go even with community features. The project was created to demonstrate production-style business application development with Jmix best practices in domain modeling, UI, security, and business logic. github.com

Another good example is Flowset Control Community, a real product built by Haulmont Technology with Jmix. It is a web application for administrative work with external BPM engines, covering practical tasks such as connection management, deployment, process browsing, instance management, and user task reassignment. This shows Jmix not only in a broad business-system scenario, but also in a focused operational tool with real workflow complexity. (github.com)

Together, these two applications show Jmix in realistic product shapes that developers and architects can immediately relate to. One demonstrates a mainstream B2B business system, the other a specialized operations product. Both are open source, based on real requirements, and useful as inspiration for teams building new digital products with Jmix.

New architectural patterns

In 2025, Jmix addressed an architectural challenge that becomes important for teams building larger enterprise systems: how to split a growing application by business domains without forcing the team into microservices too early. The solution was the REST DataStore add-on. It lets one Jmix application work with data and services exposed by another Jmix application through the generic REST API, while still using familiar Jmix development patterns such as DataManager and standard CRUD flows. In practice, this means teams can connect Jmix applications to each other without writing large amounts of custom integration code.

For developers, this creates a practical new way to assemble Jmix systems. Applications can be separated by domain and combined into a distributed monolith architecture: more modular than a single large application, but much simpler to build and operate than a full microservices architecture. The same approach is also useful for splitting frontend and backend into separate Jmix applications, where the frontend works with backend data through REST DataStore while preserving standard authentication, user settings, filter persistence, and file access patterns. This gives teams cleaner boundaries, less accidental coupling, and a more gradual path to scaling the system over time. Because REST DataStore is delivered as an add-on, teams can adopt this pattern step by step instead of redesigning everything at once. Based on our internal download statistics, its popularity in the Jmix community is growing quickly.

Community work

In 2025, we put more emphasis on practitioner-led stories and practical webinars that showed Jmix through real implementation scenarios. That included sessions on building scalable business systems with Jmix, using Jmix as the foundation of an internal development platform, moving from idea to working product, and building applications closer to real business use cases. This made Jmix easier to evaluate through delivery, architecture, and adoption experience rather than through feature lists alone.

Jmix was also presented in broader Java and partner communities, including Vaadin Create in Frankfurt, JUG Istanbul, meetups in Vietnam, Kazakhstan, Uzbekistan, and SMAU in Milan. The Vaadin Create appearance was especially important for the Jmix team: it put Jmix on stage in front of the broader Vaadin community and reinforced the alignment between Jmix and the Vaadin ecosystem around modern Java business application development. It also opens the door for new joint offerings from the Jmix and Vaadin teams for the Jmix community.

What we learned from Jmix users in 2025

In 2025, one thing became very clear: teams get up to speed faster when they can learn Jmix step by step instead of trying to absorb the whole platform at once. Over the year, we filled in the learning path much more systematically:

Another strong signal came from Jmix AI Assistant inside the IDE. The decision to place it directly next to the project and the code proved right: adoption grew extremely fast, and based on our internal product observations, it is now approaching the popularity of long-established Studio features such as Entity Designer. During 2025, the project also matured technically: the AI backend was rebuilt as a Java-based Jmix application and published as an Apache-2.0 open-source project, so the community can inspect the architecture and reuse the implementation experience.

Visual helpers in Jmix Studio such as View Designer, JPQL Designer, and Code Snippets show good adoption. They remove routine friction inside the normal developer workflow. Following the same logic we reworked Hot Deploy for quicker iterations: in Jmix 2.5, Studio started showing a clear hot-deploy status indicator for supported files, making it much easier to see whether the latest changes had already been applied to the running application. This is a good example of the kind of visual tooling that works well in Jmix: not heavyweight visual programming, but practical IDE assistance for developers.

At the same time, 2025 showed where we needed to change direction. The BPM Modeling tool in Jmix Studio demonstrated weak adoption, so we decided not to continue treating it as a core Studio capability. The BPM area itself is still growing, and we will continue investing in it, but with a different priority: making the runtime BPMN modeler a first-class part of the platform. The existing design-time modeling functionality was delivered to the new product, Flowset, and users who still want visual BPMN editing in the IDE can continue through a dedicated Flowset Studio plugin path.

Another clear growth signal came from the Multitenancy add-on. Adoption increased quickly, showing that more teams are using Jmix to build B2B SaaS applications. That growth brings a new product challenge with it: better support for end-user teams that want granular tenant-level customization at runtime without direct code access. This is one of the priorities for the Jmix platform.

2026 roadmap

What agentic programming to AI stewardship

Agentic programming changes the cost of implementation, but it does not remove the engineering responsibilities of enterprise software. Faster CRUD and early prototypes are cheaper than ever. That is real progress. But enterprise teams are not judged by how quickly they get a first version on the screen. They are judged by whether the result is secure, maintainable, scalable, and fit for production use.

For Jmix, this changes the baseline. The value of a development platform is no longer in code generation alone. It is in how well the platform helps teams keep control over architecture, data access, security, and long-term maintainability while using AI-driven development tools.

This is where the idea of AI stewardship becomes important for us. We use this term deliberately. An assistant helps with a task. A steward helps a team move faster without losing control of the result. In Jmix terms, that means AI should support developers and business users inside platform conventions, security constraints, and architectural rules, not bypass them.

It also means taking seriously the environments where public AI services are not an option. Many enterprise teams want to adopt AI-driven development, but they also need controlled deployment models and enterprise-approved infrastructure for working with sensitive project context. For us, this is not a side case. It is part of what enterprise AI adoption actually looks like.

What becomes high priority for Jmix

These changes affect Jmix Studio and Jmix Framework differently.

For Jmix Studio, the main change is that raw code generation is now cheaper than ever. Faster CRUD and first-draft prototypes are no longer a strong differentiator by themselves. What matters more is how effectively developers can work with a real project together with modern coding agents.

Because Jmix Studio works inside IntelliJ IDEA, we see its future not as a standalone AI environment, but as part of a hybrid development workflow. Developers can already use CLI coding agents such as Claude Code, Codex, or OpenCode in the IDEA terminal, or connect agentic tools through plugins available in the JetBrains Marketplace, including JetBrains’ own Junie, alongside options such as Continue and Kilo Code. In this setup, Jmix Studio does not replace those tools. It complements them with project-aware support for Jmix applications inside the same working environment. To make that experience smoother, we also prepared the Jmix AI Agent Guidelines, which help developers and coding agents work with Jmix projects using consistent patterns, rules, and best practices. We remain confident that IDE-based development will stay essential for enterprise-grade projects, where teams need structured navigation, inspections, explicit project context, and tighter control over what is being generated and changed.

Another priority for Studio is project awareness. Smart inspections in Studio help agents identify mistakes in generated code early through the JetBrains MCP integration, before those mistakes turn into failed builds or longer debugging loops. In practice, this reduces the number of generation-fix-regeneration iterations and shortens the path from prompt to working result.

For developers, project structure awareness solves a different problem. When Jmix Studio makes screens, entities, data flows, and application modules easier to understand, it becomes much faster to enter an existing project, navigate its logic, and make targeted changes with confidence.

For the Jmix Framework, the priority shifts from faster initial implementation to stronger runtime flexibility, tenant-level customization, and stable architecture under continuous change. Another important factor is keeping the Jmix development model compact and explicit. Clear code conventions, predictable project structure, and high-level framework APIs mean that agents do not need to generate as much low-level code to achieve useful results. Less boilerplate means fewer tokens spent, fewer places where generation can go wrong, and less code for developers to review afterwards.

One more Framework capability becomes more important in the AI era: the built-in security subsystem. As soon as developers start building AI-enabled enterprise products, they need to connect LLM-driven tools with business data. This is exactly where security becomes critical. With Jmix, teams do not need to reinvent a secured data access layer or build a configurable permissions model from scratch. They get role-based access control and configurable permissions out of the box. That makes it much easier to expose data safely not only to end users, but also to AI agents and backend services working inside the same application boundaries.

How these priorities map to our product streams

These priorities come together in three main product streams.

AI stewardship

The first stream is AI stewardship. We use this term to describe AI capabilities that help teams move faster without stepping outside the engineering, security, and governance boundaries of enterprise software. In practice, this means AI should work through Jmix conventions across all steps of the software development lifecycle instead of bypassing them.

This stream includes initiatives such as Text-to-UI Builder, which introduces a new way to work with Jmix views: developers can change the UI layout by text instructions while the agent applies the changes directly to the project source code. The feature is intended for Jmix Studio dev mode, when Jmix Studio and the application runtime are opened simultaneously, so layout changes can be described, generated, and verified in one continuous workflow.

The same stream also includes Text-to-Data Add-on, which turns natural-language requests into controlled framework-level data access. Developers will be able to use it in different implementation areas: for example, inside the Chat UI component to surface application data insights into the UI, or inside the BPM system to support autonomous agentic-powered services. The same guarded approach will also be extended to reporting scenarios through LLM-powered Data Query support in Reports.

The stream also includes planned support for enterprise-controlled AI deployment. For many teams, AI adoption depends not only on usefulness, but also on where models run and how sensitive project context is handled. That is why this stream also covers controlled environments, including self-hosted and enterprise-approved LLM infrastructure.

Dynamic runtime

The second stream is dynamic runtime adaptation. The main idea is straightforward: let teams change more of the application after deployment, without turning every change into a source-code task.

The strongest direction here is the ability to redefine parts of the data model at runtime. Around that core, we also want to expand what can be adapted in the running application: UI composition, reports, BPM-driven interactions, chat-based interfaces, dashboards, and spreadsheet-style workspaces. This matters most in SaaS and multitenant applications, where tenant teams increasingly want granular customization of behavior without direct access to the codebase.

In practical terms, this stream is about moving more change capacity into the application itself. Instead of sending every adjustment back to developers, the platform should give business teams, tenant administrators, and product teams more room to adapt the system where the change actually happens — in runtime.

Reference applications

The third stream is reference applications. In the AI era, feature descriptions alone are not enough. Teams need operating software they can use as a starting point for their own products.

This is why reference applications remain an important part of how we develop and communicate Jmix. Today, this portfolio already includes applications such as Bookstore, Wind Turbines, and the open-source B2B CRM sample, each showing Jmix in a different and recognizable business scenario. In 2026, we plan to enrich this portfolio further, so developers and architects can evaluate Jmix through a broader set of practical software examples rather than through isolated feature descriptions.

You can follow the current Jmix roadmap on the GitHub project board.

Looking ahead

March 2026 is an important transition point for the broader Jmix ecosystem. In the previous annual recap, we explained why the team decided to prolong free support for CUBA Platform until March 2026 instead of switching fully to commercial support earlier: migration demand remained high, transition effort was still significant for many customers, and some important UI capabilities in Jmix 2.x still required more time to mature. That extension was intended to give the community a longer and more realistic transition window. By now, those blockers have been addressed: the migration path has been designed more clearly, and the key UI capabilities needed for transition have been delivered. As announced earlier, free maintenance for CUBA Platform now ends in March 2026, and after that support will remain available only under commercial maintenance contracts.

To support that transition in practice, we prepared agentic migration scenarios for moving from CUBA Platform 7.2 to Jmix 2.x. The goal was to give existing CUBA Platform customers a more structured path to modern Jmix technology. The public migration repository includes instructions, templates, and guidance for AI-assisted migration work, so teams can approach the move with less manual effort and less uncertainty. For us, supporting this transition is not only a migration task, but also a natural part of how an enterprise platform should treat continuity for the teams that have grown with it.

Finally, 2026 is a milestone year for the technology line behind Jmix. It marks the 10-year open-source milestone of the platform family that evolved into Jmix. That is a simple but important reminder: Jmix is not a newcomer in enterprise development. It is a mature technology with a long product history, enterprise customers, and a community spread across different regions and industries.

We are planning dedicated anniversary content for the community throughout the year, so there will be more to share soon.

Develop smart, not hard!

Follow Jmix on LinkedIn

for product updates and expert insights

Follow on LinkedIn