“CUBA” becomes “Jmix”! It is a big rebranding, but it is worth all the effort. This name is much simpler to explain: “J” for “Java” and “mix” for the technologies and frameworks mixed in one application.
Effectively Jmix is the next major CUBA version with well-known APIs and development approach. And it is still the same set of convenient tools and code generators.
With Jmix, we try to achieve the following goals:
- Better developer’s experience. Modern frameworks are simple to use, easy to configure and provide a big library ecosystem.
- Re-use existing solutions as much as possible. Do not reinvent the wheel.
- Smaller app footprint, only functionality which is absolutely necessary should be in core.
- Powerful tools - keep great experience and development speed.
Let’s have a look at the framework and things that we’ve implemented to achieve those goals.
Core
The most noticeable change: Jmix is based on the latest stable Spring Boot framework version instead of “pure” Spring. Using Spring Boot gives us the following advantages:
- Familiar experience. Currently almost every Java developer has experience working with Spring Boot. With Jmix, Spring Boot development skills can be used at its full, no need to learn a new framework.
- Jmix relies on existing infrastructure with huge community support and a tremendous documentation base. In Jmix we got rid of many features that were implemented in the previous version in favour of the “standard” libraries.
- Simplified deployment, including great containerization support, out-of-the box. In the simplest case, you don’t even need to create a Dockerfile to create an image for your application.
In Jmix, we continue to move all “optional” functionality to add-ons. An “empty” Jmix application contains less functionality “out-of-the-box” than a CUBA application.
Even data access services and security management - are in the separate modules in Jmix. But those add-ons are included by default when you create an application in Jmix Studio. Let’s have a closer look at those modules.
Data Access Layer
Data Access Layer is a cornerstone of any data-centric application, and we took the best parts of it from the CUBA framework: optimistic locking functionality, soft deletion, cross-datastore references, etc.
With all the advantages, CUBA data model has one fundamental flaw: it is pretty rigid. For example, if you needed soft delete, you had to implement a proper interface (or inherit your entity from BaseEntity) and introduce columns with predefined names in the corresponding table. All primary keys had to be stored in the column with the id name if you used the StandardEntity class.
In Jmix, the Entity model becomes more flexible. We decided to deprecate interfaces that specify entity functionality. They are replaced with common annotations.
All you need to do - add the annotation @JmixEntity to a class to make it accessible to the framework. We ditched some custom interfaces, you should use JPA’s @Version annotation and Spring Boot’s @CreatedBy instead of proprietary Versioned and Creatable interfaces.
This allows us to make code more explicit - you can tell which features are supported by the entity by just looking at its code.
@JmixEntity
@Table(name = "CONTACT")
@Entity(name = "Contact")
public class Contact {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "ID", nullable = false)
private Long id;
@Version
@Column(name = "VERSION", nullable = false)
private Integer version;
@InstanceName
@NotNull
@Column(name = "NAME", nullable = false, unique = true)
private String name;
@LastModifiedBy
@Column(name = "LAST_MODIFIED_BY")
private String lastModifiedBy;
@Temporal(TemporalType.TIMESTAMP)
@LastModifiedDate
@Column(name = "LAST_MODIFIED_DATE")
private Date lastModifiedDate;
Another renaming - “CUBA Views” are now “Fetch Plans”. The new name describes the purpose of these artifacts much better. Functionality stays the same though with one exception: Jmix’s data access layer now supports automatic lazy loading of references.
So if you choose not to use fetch plans for filtering out local attributes, you will never get the notorious “UnfetchedAttributeException” anymore.
In Jmix 1.0, we introduce a new experimental feature - Spring Data repositories support. Now in Jmix you can define data repositories using the well-known approach from Spring: repository interfaces. The concept was described in the blog article, now this feature is implemented in Jmix. We’re creating a developer’s guide for this feature now, but you still can try it in this release simply by creating a Spring Data interface for data manipulation.
public interface PetRepository extends JmixDataRepository<Pet, UUID> {
List<Pet> findPetsByName(String name);
}
Another big thing that should be mentioned is the database generation and update process. We decided to use Liquibase instead of the custom DB update engine. Spring Boot is responsible for running these scripts.
Liquibase can generate DB-agnostic update scripts, so if you develop a product or an add-on with Jmix, you won’t need to generate database creation scripts for all possible RDBMSes. Liquibase will use the appropriate SQL dialect depending on a JDBC driver.
Security
The Jmix security engine is built as a very thin layer over Spring Security. The data model has changed accordingly - in Jmix we use classes from Spring Security like UserDetails and SessionRegistry, so it might look a bit unfamiliar for seasoned CUBA developers at the beginning.
Roles have changed, “Resource Roles” and “Row-level Roles” have replaced “Roles” and “Access Groups”. In addition to this, we’ve added an “Aggregation Role”. This is a role that is composed from other roles - there were a lot of requests from users about this feature.
Spring security is not the easiest thing to set up but in Jmix we made this process as seamless as possible. You will be able to set access to entities, attributes, screens, as well as set up row-based security as it was in CUBA.
User Interface
Backoffice UI (a.k.a. Generic UI) stays intact. Component-based UI was a big part of CUBA and we will support it in Jmix. Support includes screen generators, UI editors in the IDE, etc. In Jmix, we have added new components like a separate Pagination component and ResponsiveGridLayout.
Please note that Jmix applications are single-tiered; there is no more “core-web” separation. This approach is simpler and fits into the modern architectural approach. If you want a separation, you can achieve it by implementing two Jmix applications: front-end with Backoffice UI and back-end that exposes an API. In this case, the UI won’t depend on the data model and you will pass DTOs to display data on the front-end or process it on the back-end.
Jmix Studio
With new Jmix Studio, you can choose one of the four templates for your project:
Single Module Application- to create a “regular” Jmix application.Theme Add-On- to create a CSS theme for your application. A theme can be installed as an add-on.Widget Add-On- this project type simplifies a custom widget creation.Single Module Add-On- the generated project structure will contain all settings specific for Jmix add-ons and a sample code: an entity, its UI screen and integration tests.
The next big thing is project navigator redesign. To assist with project development, the Studio provides a separate tool window. With this window, you shouldn’t choose between Jmix project structure and source code anymore.
Jmix project structure navigator can help with viewing configuration files, navigate through the data model, configure data stores, and many other things.
If you are a BPM add-on user, you will be able to create BPM diagrams in the design-time (beta feature). All business processes are deployed on the application start-up.
Add-ons
With Spring Boot, it is simpler to implement add-ons for the Jmix framework. Basically, those are Spring Boot starters.
On the one hand, it allows us to use almost all Spring Boot libraries, which is a great thing. On the other hand, in CUBA there were add-ons that implemented business functionality (e.g. Reports, Charts, etc.) in contrast to Spring Boot libraries most of which implement “system” functionality: database access, security, messages handling, you name it.
So we’ve reimplemented a lot of CUBA add-ons for Jmix to deliver a familiar set of features to the existing CUBA developers and to extend horizons for the Jmix newcomers.
Almost all Jmix add-ons now contain two modules that can be installed separately: program logic and UI. So, if you need good old CUBA’s Entity Log feature, but want to fetch entity changes via REST API, you can install this add-on without UI.
In Jmix marketplace you can find about 20 add-ons including Reports, Charts, Maps and BPM.
Deploy
Jmix uses Spring Boot build plugins for application deployment. It means that you can run a Jmix app as an executable fat JAR or deployable WAR (it also can be executed as a standalone application).
Containerization is supported in Spring Boot “by default”. To create an application image, you don’t need to create a Dockerfile. In the simplest case, issuing gradlew bootBuildImage command should be enough to have a Docker image created and uploaded to an image repository.
For cloud environments, any Jmix application is “just another Spring Boot App”, so all deployment manuals can be applied for Jmix.
Migration from CUBA to Jmix
First thing: we are not going to abandon CUBA. Version 7.2 is going to be long-term-supported and will be supported for five years. And after that, there will be commercial support available for the next five years. So, CUBA framework will live for at least next 10 years.
Migration functionality is being developed to provide as slick a process as possible in Jmix Studio. If you are eager to migrate from CUBA now, you’ll need to do it manually. We plan to deliver automated migration to Jmix in version 1.1 by the end of the year.
For backward compatibility purposes, you can use the jmix-cuba module. This module contains most of the APIs implemented in CUBA. So, you won’t need to change your code much in order to migrate to the next framework version.
Conclusion
Jmix is the next big step in CUBA Platform evolution. With Jmix 1.0 you can start implementing your applications using all new add-ons and visual designers that we provide you.
Now you can enjoy almost all Spring Boot starters and use techniques applicable for the most popular Java framework in the world. At the same time you still have all the convenient and familiar APIs and functionality provided by Jmix - a CUBA descendant as well as great development experience with the new Studio.