Several traditional ORMs do not fully honor Java module encapsulation (JPMS). This often means a lot of unnecessary files and classes are used when deploying microservices. The latest major release 3.2 of open-source
Speedment solves this problem by introducing module system support allowing efficient deployment of cloud applications and providing a more stringent API.
In this article, you will learn what’s new in Speedment 3.2 and how you can deploy cloud database applications that are 10 times smaller and using much less memory.
Support for Java Platform Module System (JPMS)
The biggest feature in Speedment 3.2 is undoubtedly native support for JPMS. Every module in Speedment now contains its own
module-info.java file and honors strict encapsulation.
As a developer, it is completely optional to use the module system and thanks to its multi-release JARs, Speedment can still be run under Java 8. You can elect to migrate to JPMS now, later or never.
Other ORMs, such as Hibernate, might support parts of JPMS but does not honor strict encapsulation (e.g. requires
--add-opens to be added manually, thereby bypassing protection from accessing internal/protected classes).
Optional Modules Allows Smaller Microservices
The Speedment modules have been internally restructured to reduce inter-module coupling. As a result, some of the modules are now optional, allowing even smaller microservices to be deployed. For example, the various database connectors are now individually pickable and the
JoinComponent is also optional.
The need for several internal modules (such as “lazy” and “mutable-stream”) has been eliminated and some of the others have been optimized and reduced in size.
Thanks to the module system, internal classes are now fully hidden and are even protected from deep-reflection. This strengthens the API (because only intentionally visible classes and methods are accessible) and therefore allows for future migration of internal classes without affecting the public API.
Cloud Deployment Example
It is possible to create a custom JRE + application + speedment libraries that is 10 times smaller and that is using 25% less memory compared to running the application under a standard JDK. If you have a large number of microservices running in the cloud this adds up to a huge difference.
The following example is further described in my article “
Java: How to Create Lightweight Database Microservices”. The database application connects to a public MySQL cloud instance of the “Sakila” database with films, actors, etc. It retrieves the ten longest films and prints them on the console in length order.
The custom JRE still has all the bells and whistles of a real JVM like garbage collect, JIT-compiler, etc. It is just the unused modules and tools that have been removed.
The application will produce the following output:
It turns out that the storage requirement for the standard open JDK 11 is 300 MB compared to the custom JRE which only occupies 30 MB (even including the application and the Speedment runtime). Thus, it is possible to reduce the storage requirements by about 90%. When examining heap usage with
jmap, it was concluded that the RAM usage was also reduced by about 25%.
How to Get Speedment 3.2
New users can download Speedment 3.2 using the
Existing users can just update the speedment version in their
pom.xml file and re-generate the domain model by issuing the following command:
That’s it. Now your old Speedment application will run under the new version.
If you want to use the module system, add the following
module-info.java file to your Java 8+ application’s root:
(*) Depending on the database type, you have to replace the MySQL module with the corresponding module for your database. Read all about the various database connector modules
Published on Java Code Geeks with permission by Per Minborg, partner at our JCG program. See the original article here: Java: Release of Speedment 3.2 – Now Enabling Lightweight Database Microservices
Opinions expressed by Java Code Geeks contributors are their own.