I hope that smooth migration to Jmix will not be a problem.
We released our solutions on the 6.8 platform.
After 2 years, we took the time to upgrade to API 7.2.
But migration at 7.2 was now our conscious decision. We wanted to take advantage of the new API.
But we could stay at 6.8 for another 2 years without losing basic platform support.
I hope that now we will have the same possibility of smooth migration before the expiration of the basic five-year support for the platform.
So I posted this in Support, but it’s probably more appropriate here:
"What is the recommendation, for a company in our position, about 20-40% through a conversion of a very large, commercial application from an ancient legacy language/environment to CUBA (or Jmix?)
Convert what we have converted to CUBA to Jmix and go forward, or keep forging ahead in CUBA? 5 years isn’t that long (our app began development in the mid-1980s…)
Some advice/recommendations would be good."
@stukalov is fairly familiar with where we are at.
1 Like
In my situation is an ERP, I “need” to be updated because If I wait to update, later can be a pain.
Congratulations, you guys made a great product already, so I trust your plans for the future.
Spring Boot, microservices, Kubernetes, more modularity are definitely good things to have, and by not going forward, the product would become obsolete, so you had no choice anyhow.
and using “standard” parts of the framework will free your resources to do more.
JS GUI will hopefully bring less maintenance to bpmn-js implementation in bproc…
Five years of maintenance is fair, that’s the average life of a frontend.
Thank you for being sincere about it, many companies would be transitioning with less dramatic cut, making the transition “evolutionary” by adding the new features and deprecating old ones.
I will stay with you, as long as you do not change the licencing model.
However, you will have 6 months after the release of 7.3 and before Jmix 1.0.
Current features of the CUBA studio, like visual design and code generation, both Java and SQL, must remain and work, as well as integrated security.
Hopefully, you will have ready essentials like Reporting, BProc, Maps, Charts/Dashboards, GrapesJS, Email Templates. Multitenancy working across that line of modules uniformly would be a good seller.
Some sort of official Haulmont chat module would be nice to see, or integration with MS Teams, Discord and such.
Kind regards,
Mladen
3 Likes
Congratulations team!! It has always been good experience using new versions of CUBA-Platform and hope the move to the new platform JMIX will be not rough as usual. This is definitely a good step moving to Spring boot platform and support react JS / react Native for front-end app where the studio is continue to support development rapidly.
@jon.craig, replied in the original thread 
- In light of the Jmix announcement - what is the recommendation? - #3 от пользователя stukalov - CUBA.Platform
Hello CUBA / JMIX team, this is really a big announcement!
I have another question regarding the porting of a CUBA application to JMIX or in general regarding JMIX architecture.
At the moment, with CUBA platform, when you write the screens using the generic UI, all the “client” application logic is written in Java because generic UI is based on Vaadin.
When you write the screens using the Frontend UI the “client” application logic is written in Javascript because here we use React JS (for services or API we continue to use Java).
With “client” application logic I intend the code you write, for example, to handle the click on a button on the user interface, enable/disable some field, etc…
With JMIX the architecture remains the same, so all the client React logic must be written in Javascript or Typescript? In this case the migration to JMIX of an “old” CUBA application that does not use React will be more difficult (migration of some Java code to Typescript).
Or did you architect some solution similar to Vaadin that allows you to write client logic in Java because the events are precessed server side?
Another question: I suppose the new architecture (Spring Boot + React + modularization) will facilitate the development of big applications splitting them in little pieces not only at server level but also at client level (micro frontends), right?
Thank you very much for your work!
Marco.
Regarding the UI, currently Jmix is not different from CUBA: you can create either Backoffice UI in Java/XML, or Frontend UI in React/TypeScript, or both. It’s described here.
Regarding migration from CUBA, the compatibility module contains even the old screen API v.6, so it will be possible to migrate UI written for CUBA 6 without major rewriting.
Regards,
Konstantin
1 Like
Is Kotlin going to be supported?
1 Like
This is in JMix documentation:
[Backoffice UI] allows you to develop the rich web UI using just Java/Kotlin and XML. In this case, your UI components work in the same JVM as your backend, which simplifies working with data and invoking business logic. Also, you don’t have to be familiar with the modern JavaScript/HTML/CSS stack.
Sure.
After few attempts this error resolved
The good news is that it doesn’t look all that different to 7.2. The main difference is it now uses Spring Boot as a foundation, which is a good thing because Spring Boot is genius.
No Kotlin support as yet, so I’m sticking with 7.2 for an existing project.
It doesn’t look like they’ll be upgrading to a later version of Vaadin, which is a shame, but would be a lot of work, and with no easy upgrade route.
But another layer on top of Spring Boot … Not sure. I’m just thinking why not use Spring Boot, Spring Data and Vaadin. 
Hi…
It was nice to see the Cuba Platform is evolving into JMIX… If possible can you please elaborate us the reason, why Cuba Team chosen Spring Boot instead of Quarkus…?
I personally feel Quarkus seems to be a better option than Spring boot… But i also presume that the might’ve did the benchmark comparison… It would be nice if you share the reason…
Thanks…
Hi @Narayanan,
Thank you for your question - this is a good one. There is a list of different reasons , let me share some from the top of it:
- Spring ecosystem is an absolute leader among enterprise developers. See this report. We build a product for the wide market and are trying to use mainstream tech.
- Jmix as CUBA is targeted at business applications, but not headless microservices. The whole point of Quarkus, as well as Micronaut, is to minimize memory footprint and boot time. These two are not the case for business apps.
- Quarkus introduces its own modules and not compatible with vast Spring Boot starters, which are even hard to compare…
- Quarkus is a member of JavaEE family, while CUBA always used Spring. So, for the majority of CUBA community, it seems to be much easier to adopt Spring Boot and migrate their existing apps.
Regards,
Aleksey
5 Likes
Hi everyone,
The 0.2.1 bugfix version of the Jmix plugin has been released to the JetBrains plugin repository.
If your IDE doesn’t see the update, please uninstall the plugin and install it back from the Plugins -> Marketplace tab.
List of fixes:
- NoSuchFieldError in CubaKtClassOrObjectTreeNode when opening the CUBA project with Kotlin entities
- Fix support of calculated properties in Entity Designer
- Add quick fix for “Instance name is missing” inspection
- ArrayIndexOfBoundException on the first page of project creation wizard
- ClassNotFoundException during start when using plugin with IDEA Ultimate Edition
- NoClassDefFoundError when using Jmix plugin while having Kotlin plugin disabled
- Suggest additional data types for Calendar properties in Component Inspector panel
- Unnecessary deletion of a unique constraint in the MySQL DB
2 Likes
Impressive agile progress.
Hi Cuba team
All this moves look very good to me. However, It’s not clear where we are heading to with current Vaadin 8, Are we upgrading it to 14 or moving completely to any other frameworks? Vaadin 14 looks very good and the PWA capability.
Ops…
Intellij IDEA Community 2020.3 does not see an update of Jmix plugin.
But after deleting 0.2, detects and installs the new version.