Right for the upcoming holidays, we are happy to announce Jmix - a new name and a new major release of CUBA Platform. Jmix has been the focus of our work throughout 2020 and is a milestone release introducing new modular architecture with Spring Boot as core technology.
Jmix is still in Preview and we are aiming to release a Stable version in Q2 2021. However, it should already be good enough for evaluation and POCs.
Key features of Jmix:
Spring Boot as a core technology
Decomposition into separate pluggable modules (data, security, audit, etc.)
A new approach to data model definition
Liquibase as the DB update engine
Deployment approach utilizing Spring Boot features, allowing better integration with cloud environments.
You can find more details about Jmix features, the ideas behind them and next plans in our blog.
If you are already developing with CUBA Platform - no worries! The latest release will be supported for a long time and we are providing a migration path to Jmix via compatibility APIs.
We hope you’ll love Jmix and encourage everyone to give it a try and share feedback!
Could I think then that with JMIX I could connect and manage non-relational databases, since its core is based on Sprint Boot? or is that still a very distant reality? It would be very productive to take Quarkus features, I have tried it and I liked very much the speed and simplicity of it.
How? Again?
We only completed the migration to API 7.2 a week ago and revolution again?
And seriously - excellent dynamics of development.
If migration to Jmix doesn’t cost a lot of blood, it’s just going to be great!
I went to set previews.
But with the name “Cuba” is sorry to part (my opinion)…
Jmix sounds bright, but “Cuba” is more soulful.
We only completed the migration to API 7.2 a week ago
This is the first thing I though. One of the things to come to CUBA for us was a stable platform where develop. Now, another big change next year, meaning hours and hours to adapt and rewrite probably
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.
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.
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.
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.
krivopustov
(Konstantin Krivopustov)
Split this topic
#16
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.
[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.
-