Java: Release of Speedment 3.2 – Now Enabling Lightweight Database Microservices
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 ownmodule-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 theJoinComponent
is also optional.
Size Reduction
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.
Strong Encapsulation
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.
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 | final Speedment app = new SakilaApplicationBuilder() .withPassword( "sakila" ) .build(); final FilmManager films = app.getOrThrow(FilmManager. class ); System.out.println( "These are the ten longest films rated as PG-13:" ); films.stream() .filter(Film.RATING.equal( "PG-13" )) .sorted(Film.LENGTH.reversed()) .limit( 10 ) .map(film -> String.format( "%-18s %d min" , film.getTitle(), film.getLength().orElse( 0 )) ) .forEach(System.out::println); |
The application will produce the following output:
01 02 03 04 05 06 07 08 09 10 11 12 | These are the ten longest films rated as PG- 13 : GANGS PRIDE 185 min CHICAGO NORTH 185 min POND SEATTLE 185 min THEORY MERMAID 184 min CONSPIRACY SPIRIT 184 min FRONTIER CABIN 183 min REDS POCUS 182 min HOTEL HAPPINESS 181 min JACKET FRISCO 181 min MIXED DOORS 180 min |
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 withjmap
, 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
Initializer.
Existing users can just update the speedment version in theirpom.xml
file and re-generate the domain model by issuing the following command:
1 | mvn speedment:generate |
That’s it. Now your old Speedment application will run under the new version.
If you want to use the module system, add the followingmodule-info.java
file to your Java 8+ application’s root:
1 2 3 4 | module your.module.name { requires com.speedment.runtime.application; requires com.speedment.runtime.connector.mysql; // (*) } |
(*) 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
here.
Resources
The complete Speedment release note history can be found here
Speedment on GitHub
The Speedment Initializer capable of generating project templates
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. |