Eclipsestore 1.2 is available

Version 1.2.0 is a smaller update, but if you use Java 21.0.2 or newer, we strongly recommend you to upgrade.

AVOIDING JVM CRASHES

Due to a removed check in the Garbage-First (G1) garbage collector in JDK 21.0.2 we had to adjust the cleaning code for direct byte buffers in order to avoid possible JVM crashes.

The Garbage-First garbage collector is one of the garbage collectors available in Java Virtual Machine (JVM) implementations. It’s designed to provide better performance and more predictable pause times compared to some other garbage collectors, especially for applications with large heaps. G1 divides the heap into multiple regions and uses a combination of young and old generation garbage collection techniques. It aims to minimize garbage collection pause times by performing garbage collection incrementally, focusing on the regions with the most garbage first. This differs from the traditional stop-the-world garbage collectors, which can lead to longer and less predictable pause times, especially on larger heaps.

You can see the process in the JDK Bug System: https://bugs.openjdk.org/browse/JDK-8325173.

With EclipseStore, the end result is an in-memory database application. Therefore, the performance of your EclipseStore database also depends on the JVM you use. Did you know that the latest Java versions are significantly faster than older ones? There can also be significant differences between JVM providers such as Hotspot, OpenJ9, Azul, Corretto, etc. By using the best fitting JVM for your project, you can speed-up your app up to 15%.

Which JVM do you use? Please write it in the comments below.

USING JAVA MODULE SYSTEM WITH ECLIPSESTORE

We are happy to announce that the module-infos are now back with this release. Due to build problems in the previous EclipseStore version 1.1.0 we had to temporarily remove the module-infos.

In Java 9 the module system was introduced (project Jigsaw). This allows developers to organize code into modules, each with its own descriptor file called module-info.java. These module-info files declare dependencies on other modules and specify which packages are exported for use by other modules, allowing for better encapsulation, dependency management, and improved runtime performance. This system promotes code reuse, maintainability, and scalability in Java applications. However, sometimes there can be build problems or compatibility issues with certain tools or libraries when using module-info files. In such cases, developers may choose to temporarily remove these module descriptors until the issues are resolved.

Overall, the Java module system has gained traction, especially in bigger projects and frameworks where modularity is a priority. However, its adoption rate across the entire Java ecosystem is still low. Many existing codebases still rely on the traditional classpath approach. As time goes on and tooling improves, we may see broader adoption of the module system in practice.

We would like to know from you what significance does the java module system have for you? Please write it in the comments below.

Many thanks to everyone who contributed to this version.

LINKS:

Changelog:
https://docs.eclipsestore.io/manual/intro/changelog.html

Code on GitHub:
https://github.com/eclipse-store/store/releases/tag/1.2.0