Jmix 2.0 is a major milestone in the evolution of the product. This release introduces a number of important features and brings about significant changes to the Jmix landscape. In this blog post, we highlight the updates and discuss their implications for your application projects.
For full details and upgrade instructions, make sure to visit the What's New page in the documentation.
Updated Technology Stack
Obviously the most impactful change in Jmix 2.0 is the new technology stack. The runtime part now depends on the latest versions of the foundational frameworks:
- Spring Boot 3.1, Spring Framework 6.0, Spring Security 6.1 in Jmix core
- Vaadin 24.0 in Flow UI subsystem
- EclipseLink 4.0 as JPA implementation in data access
- Flowable 7.0 as BPM engine
The new versions of base libraries have a sufficient support period ahead which guarantees a steady development of Jmix framework and applications. But the other side of the coin is that now you need at least JDK 17 to build and run your applications, and if you deploy in WAR, you need to update your Tomcat application server to version 10.
Also, the Classic UI subsystem is not included in Jmix 2.0 due to the incompatibility between Vaadin 8 used in Classic UI and the new Jakarta Servlet API and Spring 6. So to upgrade from Jmix 1.5 Classic UI to Jmix 2.0 you need to replace the UI layer. For more information about possible options, please refer to our previous blog post: Extended Support for Classic UI.
The new Studio 2.0 provides smooth migration for Jmix 1.5 applications with Flow UI.
Flow UI for Add-ons
We've implemented Flow UI for BPM, Business Calendars, Email and Reports add-ons, so you can use them now with Jmix 2.0.
The BPM add-on now has fully-functional runtime BPMN modeler and administration UI:
The new UI of the Business Calendars add-on:
The Email history view:
The report designer is now much cleaner and usable on low resolution screens:
To simplify the UI for most cases, the report designer assumes that a band has a single dataset. But if you select the Multiple Datasets checkbox, the designer will switch to a more complex view:
GenericFilter Component
The genericFilter component is now fully-functional and enables you to create configurations and custom conditions both during design time and runtime. The runtime configurations and custom conditions can be managed by end users:
CodeEditor Component
The new codeEditor component based on Ace editor enables users to view and edit code with syntax highlighting, as well as other advanced features such as different color themes:
And the same as many other Jmix UI components, it can be easily bound to your data model to edit code stored in an entity attribute.
Preventing Browser Tab Closing
A frequent problem in web applications is loss of entered data when a user accidentally closes the browser tab. Now, when an entity detail view is displayed, the browser shows a standard confirmation about leaving the page if the user attempts to close the browser tab:
You can use the setPreventBrowserTabClosing() method to turn on or off this behaviour in any view.
Quick Cloud Deployment
Developers often need to demonstrate their application to users, management or colleagues. It's easy if you can do it directly on your local computer or if you have a CI/CD pipeline deploying your code to a demo or test environment. But if you are a solo developer and you need to showcase your application to people on the other side of the world, the best option is to deploy it to the cloud.
Studio now allows you to do this in a few simple steps that don't require any specific knowledge about deployment or clouds:
- Register an account on AWS
- Install Docker on your local computer
- Go through a few steps of the Quick Cloud Deployment wizard in Studio.
As a result, within minutes, your application will be up and running on an AWS EC2 server, accessible to users worldwide.
Behind the scenes, Studio generates a docker-compose.yaml for your application, creates an EC2 instance through the AWS API, installs Docker on it, builds an application image on the server, and runs docker-compose with your application and PostgreSQL database containers. The database and file storage data are mapped to the server file system, ensuring that all data is preserved when you change the source code, rebuild, and redeploy the application.
This feature was considered unfinished and hidden in Studio for a long time, now in v.2.0 it's finally ready to use.
Studio UI/UX Improvements
The Jmix tool window now displays a section with all Spring beans defined in the project:
You can also group the beans and other elements by packages using this option:
The Beans section displays only beans defined by the @Component or @Service annotation on the bean class. Beans created in Java configurations using the @Bean annotations are not shown here.
The Inject dialog now displays all beans defined in the entire project classpath, including the ones defined in Java configurations with @Bean annotations. The Other Beans section have smart grouping to simplify discovering of available beans:
You can also group the beans and other elements by packages using this option:
There was a topic on our forum, where the user complained that Studio generates code which immediately produces warnings from IntelliJ like "something can have 'final' modifier". We thought that it was a fair point and Studio should comply with the default set of IDE inspections. As a result, all generated code now includes the recommended final modifiers. If you don't like it, you can adjust the Jmix plugin settings and disable this option on the Project Settings tab.
Another improvement that affects generated code is that now OffsetDateTime type is used for timestamps in Audit of creation, Audit of modification and Soft Delete traits. So the database will store the timestamps with timezone.
BPM in Studio
If your project includes the BPM add-on, the Jmix tool window now has the BPM section. The section displays BPMN processes, process drafts and DMN tables:
You can copy process definitions between the Process Drafts and Processes folders using the action buttons at the top of the modeler window. This allows you to organize a simple workflow: you work on the process definition in the Process Drafts folder, and copy it to Processes as soon as it's ready. All process definitions located in the Processes folder will be deployed at the next application start. If something goes wrong with the deployment, you can copy the process back to drafts and remove it from Processes to let the application start.
Authentication in Generic REST
In release 1.4, we introduced the Jmix Authorization Server as a preview feature. In 2.0, it became the main way of authentication in Generic REST. The motivation for this change is twofold. On one hand, the old Jmix Security OAuth2 module cannot be used in Jmix 2.0 because it depends on outdated Spring Security OAuth, which is incompatible with Spring Boot 3. On the other hand, we should follow best practices and get rid of deprecated OAuth password grant flow.
Now if you are using Generic REST add-on, you have to choose the grant type, which determines how the REST clients will obtain access tokens. Jmix Authorization server supports two grant types: Client Credentials and Authorization Code. They both have an advantage over the Password grant in that they don't allow the client application to collect or possess the user password.
The most similar to the old Password grant and easiest to implement is the Client Credentials grant. It should be used for server-to-server communication, such as integration with a third-party system. In this case, the configuration of Jmix Authorization server includes the association between the client and the list of existing application roles, e.g. rest-minimal, order-management, etc. To obtain the access token, the client just needs to pass its client-id and client-secret in the basic authentication header. Subsequent API calls with this token will have the security context of a special user with the username equal to client-id and the list of roles configured for this client in the application properties. In other words, the client receives the static set of permissions and never operates as a real application user.
The Authorization Code grant is more complicated but it allows the client to work on behalf of the real application user. With this grant type, when the client requests authentication, the Jmix Authorization Server itself shows a login page for the user to enter their username and password. Then, it returns an intermediate authorization code to the client. The client exchanges the code for the access token and uses the token for API calls. Thus, the client operates as a user without ever knowing the user's password.
Conclusion
With the introduction of the fresh technology stack and production-ready Flow UI, the Jmix platform completes the modernization phase and moves on to steady development. Our team will continue working on implementing new features and constantly improving the overall quality of the product.
In the next feature release scheduled for October 2023, we have planned several important updates. This includes the implementation of Flow UI for several more add-ons, the addition of SuggestionField and SettingsFacet to Flow UI, and improvements in support for data repositories. Our detailed roadmap for the future releases is published as a GitHub project.
We welcome your feedback on our forum, and thanks to all who contributed with their ideas, suggestions and bugreports!