Good afternoon, first congratulations on the new version of 2.4, very interesting new contributions that contribute to improve the product. In our company we have been waiting a long time for this version because we believed (perhaps mistakenly) that the functionality to group by columns in the DataGrid would be implemented, also allowing to be able to do summations, etc, on these groupings, in short a functionality that has accompanied the different versions of Cuba for many years and that was not integrated in the new developments for Jmix.
We have several applications developed and about 1,500 users using them, this functionality is very important to us, so much so that we did a survey for the possible migration to Jmix, explaining to users that they would not have this functionality available, the response was unanimous, they preferred to continue using the versions based on Cuba rather than migrate to Jmix and that it did not have this functionality.
The company’s management was not happy that later versions of a platform did not contemplate the possibility of having some very implemented improvements (this one among them but also others), coinciding also with the increase in the price of licenses that was made (which we saw it logical and positive because the product deserved it), but it is difficult to explain these increases in subsequent versions of the product do not have previous functionalities.
Sorry for the long text, but I think it is convenient to show how some things (even if they are small) can affect the development of a company, for now we are still frozen in the update to Jmix and although we have seen that it is possible that next year this functionality may be available, it is a long way to go after waiting quite a long time for it.
Can there be an alternative so that this functionality is available sooner without having to wait for the new version next year?, and thus be able to plan and begin the migration of all our applications to Jmix.
Thanks and greetings.
Hi @albertosanchez,
welcome to the forum 
I’ll try to give you some context based on my observations as a interested Jmix user about this topic. Just to clarify, this is purely my personal take on the whole matter and I have no further insides besides what is written here in the forum / the wider internet.
First of all I can understand how challenging it is when you have a running application that heavily relies on features like grouping, and then you find out it’s not available in a new version and now it seems you’re stuck somewhere in the middle.
Because I have seen this feature request quite frequent in this forum, I would assume almost everyone in Haulmont is aware of the importance of this feature.
Observation & Speculation
From what I’ve observed, Vaadin (both in version 8, which is over a decade old, and in the current versions) has never supported grouping in the DataGrid (in fact not even in the Table component). This isn’t new to the Vaadin Company - it has been raised as a feature request as far back as 2017 from a former CUBA Platform developer (Grid with grouping - Vaadin Forum). but has never been implemented.
I suspect there are two main reasons for this:
- there’s less demand for it than we might expect (even though a lot of really big enterprises use Vaadin in there very own systems, so the target audience is most likely there).
- It’s extremely difficult to implement.
I would assume it is a combination of both of those things.
In CUBA, grouping was possible. But even in CUBA, it relied on a “hacky” solution: sorting the data so that the group aggregation results were not broken. While it partially worked, this wasn’t really optimal.
From what I imagine, grouping probably clashes with some fundamental design decisions of the DataGrid itself, mainly: how to combine it with pagination. Grouping typically requires aggregations (like totals, counts, etc.) across the entire dataset, which doesn’t fit well with server-side pagination, where only part of the data is loaded at a time. While you could try workarounds, like performing additional grouped queries to calculate these aggregate values on the server or loading all the data for grouping, these are far from trivial solutions.
The fact that Haulmont hasn’t implemented it, even though the Vaadin Data Grid has existed since a lot of years (at least in Vaadin 8 it was already present), further highlights how challenging this is. But what I think is even more telling is that Vaadin itself hasn’t implemented it in years.
As for Jmix, if I recall correctly they initially planned to tackle grouping for data grid in 2024, but this has now been pushed back to 2025 from what I read. To me, that shows just how complex the implementation must be. I’m not sure about the internals of the Grid component, but I think it is the most complex component in Vaadin. So trying to put it into the component without “owning” the source code (form a Jmix PoV) seems to be even more challenging compared to if Vaadin would built it directly into the framework.
Suggestions
After thinking a little about what practical options might be possible, here is a short list of more / less realistic solutions that I was able to come up with. Since I don’t know your / your companies context I cannot judge on the likelihood in your case, so I will just list all the ones I could come up with.
1. Stepwise migration
You could migrate to Jmix 1.x first, where the Group-Table component is still available (see here). This way, you can keep the grouping functionality while also benefiting from the Spring Boot foundation (and other improvements) of Jmix.
A stepwise migration allows you to split the work: first, address the backend and non-UI changes, and then, at a later stage, handle the UI migration to Jmix 2.x. This avoids a “big bang” migration where everything has to be done at once, reducing risks and giving you more flexibility. While directly migrating to Jmix 2.x might be slightly faster, the gradual approach ensures a smoother transition.
On top of that you buy yourself time by doing the Jmix 1.x migration.
Note: Jmix support for 1.x has been extended until 2028 (see the blog post). Reading this post, your feature request might be one of those reasons, the extended support period was announced.
2. Use a different grid
If grouping is really that critical to your application and you cannot wait any longer, you could replace the grid component with one from another library. There are several options that support grouping out of the box, such as:
• DevExpress
• AG Grid
• Bryntum Grid
Integrating these into the Jmix Flow API will probably be time-consuming when you want to built a server side API for it. A simpler alternative might be to build a standalone JS application with the grid and embed it via an iFrame in your Jmix app (which is somewhat of a hack, but might work). The JS app could interact with Jmix via REST APIs. As a middle ground between those two options you could instead of building a full fletched Flow API, just built the bare minimum by keeping the majority of APIs only on the JS side. See also: Integrating JavaScript Library :: Jmix Documentation.
Keep in mind, though, that using a different grid means you’d need to replicate a lot of functionality, like permissions, filtering, etc., which the Jmix (Vaadin) DataGrid provides out of the box.
3. Have it built by Vaadin (or Haulmont)
Vaadin offers a Feature Sponsorship program where you can pay to have specific features developed (see Vaadin Blog). So this is apparently quite a common thing that companies do if they really have a specific need for it. The very recent Popover component from 24.5 is exactly this: a company paid Vaadin to built it.
Alternatively, you could reach out to Haulmont and see if they’re open to building the feature for you (faster).
This option can be costly (depending on how capable you are going for option 2 it could also be cheaper), but if grouping is critical to your application and you need this solution fast, it might be worth the investment.
4. Wait for the Jmix release
As unexciting as it sounds, waiting for the planned release in 2025 might be a valid option. If your current solution can hold up until then (or you might combine it with option 1.), it might save you significant effort.
I hope those suggestions help you a little bit
Cheers
Mario
Hi @mario the first thing I want to do is to thank you for such a detailed answer, you are a very active participant of the community and your words are very much taken into account, (how much we miss the addon to import files in Jmix 
).
Among the options that you detail we will wait for the next release to include this functionality, right now for us it would not make sense to do otherwise as we have been waiting for quite some time, maybe if we had known before we would have taken another path like the ones you indicate.
My comment was also written as a reflection on what it means in a company (ours), such profound changes in the development framework, especially when you already have a long history with the framework (we started with Cuba in 2018), and have developed many applications with it.
Developing and implementing the ‘goodness’ of the framework allows users to get used to its use (which is desirable because when choosing a framework for business development, the possibilities it offers and why it is better than its direct competition are carefully considered), after all, in this style of framework, the capacity to make business developments in a much shorter time than the standard prevails, and to provide reliability and robustness so that the business processes rest on the applications made.
In these circumstances, each framework update becomes a challenge due to the complexity of updating when there are numerous screens and code from another version.
Such difficulties constantly delay the update to new versions of the framework. After all, the company’s management wants us to spend time developing new applications and improving existing ones. Spending excessive development time just to adapt the “foundations” without seeing anything (or very little) new from the user’s or management’s perspective is very difficult to explain.
Be careful, this is the purely technical part; then there’s the user part. If users are accustomed to using certain framework functionalities (which were the reasons for choosing that framework over others that didn’t have them), and these functionalities are not implemented in a new version, the version simply cannot be updated until they are implemented. There are already established work procedures that cannot suddenly disappear, and a framework change is not an explanation that can be given to users and management. If this change also causes functionalities to disappear, it becomes even more difficult (if not impossible) to explain.
If you wait too long to update the version because there are functionalities that are not covered and the framework continues to advance, the migration becomes increasingly difficult and lengthy.
If the migration becomes practically a complete new implementation (due to the version differences), it is worth evaluating other frameworks before doing it to “compare” in case they are in a better situation, which means there is a possibility of changing the framework to another provider. This last possibility would never occur if migrations were done in a reasonable time.
I’ve written a lot already; these are day-to-day reflections that happen within our companies. I’m sure many colleagues have gone through or are going through these difficulties. I thought that by using the example of column grouping, it would be better understood, but it was just an example to understand the reflection.
I hope these reflections can help or at least be taken into account to make a better evolution of the product. We have been following the same path with Jmix for many years, and we want to continue this way.
Best regards
Hi @albertosanchez,
I’m glad my previous reply was helpful. It’s also great to hear that the file import add-on was useful to you in the past. Just as a quick note: Jmix now includes a built-in data import solution as part of its standard Haulmont add-ons (jmix/jmix-dataimport at master · jmix-framework/jmix · GitHub) - although it is still marked as incubating. It’s a more robust implementation, and that’s why I decided to not migrating my custom add-on – the framework now offers something better by default.
Coming back to your reflections: I’ve also faced similar situations in my work over the years, and I’ve noticed a few recurring themes that might resonate with what you’re describing. It is partly about CUBA / Jmix, but also about framework usage in general. Once again, I’m not privy to the inside baseball of Haulmont, so I’m just writing down what I observed.
The Framework as a dependency
When we choose a framework or library, we are, quite literally, accepting a dependency - we depend on it. And while this is perfectly natural, it also comes with trade-offs. The more a framework does for us, the more we rely on it. And let’s be honest here: CUBA / Jmix does a lot.
But at the same time, it allows us to move faster, because we don’t need to reinvent the wheel for things like user management or report generation. Frameworks like CUBA and Jmix, in particular, are designed to offer as much out-of-the-box functionality as possible, so they naturally create a tighter coupling between our applications and the framework itself.
In CUBA I also saw that this dependency often extends beyond just code. It can also influence how our end users perceive the software. For example, if we expose pre-built UI screens from the framework – things like standard user management screens or report editors – these become part of the user experience. When the framework changes or evolves, and those screens are no longer available or work differently, it’s not just a technical challenge for developers. It’s also a challenge to manage expectations from users and stakeholders, who are accustomed to the old behavior. But on the other side providing those management UIs (or end-to-end functionality shipped as an add-on) are also a key differentiator compared to the majority of other frameworks. Normally the frameworks stop at some technical layer, but not really touch the workflow end-to-end. This is a huge time-saver, but as a downside it reveals a dependency from a technical decision to the end-user of the software.
I think this is where migrations become particularly tricky. It’s not just about updating code; it’s about maintaining continuity for the people who use the software every day. And if key features are missing or delayed in the new version, it can lead to difficult decisions: Do we stick with the old version longer, knowing that it will eventually be unsupported? Or do we move forward and deal with the pain of re-implementing features ourselves? But sometimes we practically can’t, leaving us almost no real space to act. And since the exposure to the end-user is done via the user interface, it’s not something that we as app devs can easily hide through a layer of indirection. All of a sudden out of a technical problem it becomes an end-user problem.
The CUBA / Jmix Migration Path
One of the key points about Jmix 1.0 is that it was still tied to Vaadin 8. At first glance, this might seem like a limitation or a missed opportunity to adopt newer technologies. But from what I understood / interpreted, this was actually a very deliberate and thoughtful decision by the Haulmont folks, made with the best interests of developers in mind.
When Jmix 1.0 was released, Vaadin 14 was already available for quite some time. However, moving directly to Vaadin 14 would have significantly increased the effort required for application developers migrating from CUBA to Jmix. It’s not just about adopting new UI components – the changes in Vaadin 14 were so fundamental that most applications would have needed a complete rewrite of the UI layer.
Even more importantly, Haulmont evaluated Vaadin 10 / 14 at the time and decided it was not yet mature enough for production use (see Vaadin Flow – a marvelous deer – Jmix and more importantly Vaadin 10+ as the Future of CUBA UI – Jmix) . It seemed that the priority was ensuring stability and minimizing disruption for developers, so Jmix 1.0 started with Vaadin 8 for two more years (from 1.0 to 2.0 release of Jmix). This wasn’t about delaying innovation but I think about 1. prioritization and 2. about protecting developers from potential pitfalls and giving them a smoother migration path.
If you look at it from this lens, I think Jmix 1.0 was a quite good example of a risk mitigation strategy. The changes introduced were substantial, but they were also carefully staged. Instead of overwhelming developers with a “big bang” transition from CUBA to Jmix 2.0, which would have combined all the backend changes with a completely new UI framework, Haulmont split the transition into manageable steps.
As a result, developers now have options. You can decide to make a single big leap from CUBA to Jmix 2.0 and tackle everything at once, or you can take a phased approach: first migrate to Jmix 1.x, keeping the UI layer largely unchanged, and then update to Jmix 2.x when you’re ready to adopt the new Vaadin version.
The whole question of why a 2.x shortly after a 1.0 (well - actually it was two years after) and in particular why it forces to switch to Vaadin 24 is not a result of Jmix isolated decision, but a force from the underlying libraries (Spring & JPA javax → jakarta namespace change as well as Vaadins migration to Spring Boot 3 and in particular Vaadin 8 end-of-life in 2022). I discussed about that in another thread: Jmix 2.x upgrade - a practical guide for rent-your-stuff example - #7 by mario.
The wider migration landscape
If we zoom out and compare this migration to other frameworks, I think Jmix and CUBA have handled it relatively well. Over the years, I’ve been involved in several framework upgrades, like moving from Spring Boot 1 to Spring Boot 2, or transitioning from Backbone.js to React. A classic well known example I not personally experienced in production, but heard a lot of interesting horror stories is clearly Python 2 to Python 3. In the JVM world, I experienced one thing in particular, which was super painful (and thus in fact we never finished) was from Grails 2 to Grails 3.
Many ecosystems and frameworks handle upgrades much worse than what we’ve seen with CUBA and Jmix. I saw Haulmont has put a lot of effort into making the migration as smooth as possible. Tools like the CUBA Studio migration wizard helped automate parts of the process, and while it’s impossible to cover everything due to the framework’s wide surface area, they still did a pretty good job.
But let’s be clear here: It is also not fair to compare it 1:1 to purely open source alternatives. With the much wider surface area, the paid subscription model and the focus on long running enterprise applications, the stakes & expectations are much higher. It can and was expected from Haulmont to have a better migration story than a random open source framework.
What I think was misleading is that somehow people got the impression (not talking about you, but comments from the forum in general) that there will be tool that will do a migration and then afterwards they only have to click the play button in IDEA and everything will work again. I personally wasn’t really expecting that and I even was kinda positively surprised about what was there - as in other migrations I didn’t even see any kind of tooling from the framework vendors.
But I do think there was miscommunication and / or not aligned expectations for sure.
All that being said, at least for me using a framework isn’t just an asset that speeds you up 2x, 5 or 10x - or sometimes also slows you down ). It’s 50% asset and at least 50% liability. The speed gains and development benefits are clear, but they come at a price, and we as developers need to account for that. Often, business stakeholders focus only on the advantages and forget about the technical debt and maintenance effort required. At least for myself I see that as a part of my role as a technical person to remind them that using frameworks increases dependencies, which in turn makes regular upgrades and maintenance essential.
Lets look into the future
If we take a look forward and consider the dependencies we currently have up-to-date, the foundation now looks very stable. Spring Boot, as the underlying technology, is on a highly current and mature base, and I don’t expect any fundamental changes in the near future. There will be a new major Spring Framework version (Spring 7) in November 2025, and likely a corresponding Spring Boot 4.0 release around the same time. These updates will raise the baselines, probably requiring Java 17 or later, and while there will undoubtedly be some changes, Spring is a very mature framework. I wouldn’t anticipate any groundbreaking shifts.
Vaadin, on the other hand, has seen much more fluctuation over the years, especially in versions 10 through 20. During this period, they made significant changes, particularly between versions 10 and 14, but also beyond 14. It was evident that they were still searching for a consistent approach to their core technologies. They transitioned from Polymer 2 to Polymer 3, introduced LitElement, adopted TypeScript, and later added React support. This frequent switching made it challenging to predict their long-term direction.
However, things have stabilized in recent versions like 23 and 24 (and this is exactly the point when Jmix adopted it BTW). While they’ve recently added React support, the underlying framework has felt more consistent, and the overall platform appears much more stable than it did during those earlier years of experimentation. In particular now since 2-3 years they also seem to have come to more / less feature parity with their previous flag-ship product: Vaadin 8.
Because of this stability in the underlying stack, I don’t foresee any dramatic changes on the Jmix side in the next 1–2 years (beyond that anything would be guess-work anyways). Of course, there will be ongoing updates to keep the platform modern, but they’re likely to be evolutionary rather than revolutionary. Unlike the big transitions from CUBA to Jmix 1 or from Jmix 1.x to Jmix 2, I would expect the upcoming years should focus more on incremental updates and stable feature enhancements.
From what I see, the current frameworks provide a solid and modern foundation, and I expect them to continue evolving in a way that supports long-term stability for Jmix applications.
I hope this helps putting the things a little bit more into perspective.
Have a nice day!
Mario