HotSpotの反撃:JEP 544はGraalVMの起動時間独占を終わらせるのか?
HotSpot JVMにとってエキサイティングな時代が来ました。JEP 544: Ahead-of-Time Code CompilationがJava 28向けに提案されたばかりです。これにより、GraalVMの厄介な制約を一切伴わずに、HotSpotのAOTキャッシュがGraalVMに匹敵する起動パフォーマンスを得られることが約束されます。ただし、AOTキャッシュのトレーニングはGraalVMによる事前コンパイルとは異なるものです。では、両者は実際のところどのように比較できるのでしょうか?SBOMの義務化まであと15か月。あなたのSBOMはおそらく正しくない。
2027年12月11日から、EUサイバーレジリエンス法（Cyber Resilience Act）におけるSBOMの義務が適用されます。つまり、EUでソフトウェアをリリースしたいなら、間もなくSBOMが必要になります。これはEUに限った話ではなく、この宣言型のアプローチによってサプライチェーンセキュリティを強化する世界的な潮流です。米国では2021年から連邦政府向けソフトウェアベンダーにSBOMが義務付けられており、CISA/NSA/FBIは今年7月にSBOM最小要素の改訂版を公表しました。
SBOMを正しく作成するのは容易ではありませんし、ソフトウェアにインストーラーを付けて出荷する場合には、その難易度はさらに上がります。今、何をすべきでしょうか。見ていきましょう。
Migrating to install4j 12
In most cases, migrating to install4j 12 usually just involves opening and saving your project with the install4j 12 IDE. Nevertheless, there are some considerations with respect to backward compatibility and some behavioral changes.
With Temurin 24.0.2, Adoptium JDKs can again be modularized by install4j
This year we had some dramatic moments starting in April with the release of Temurin 24.0.0 from Adoptium, our default JDK bundle provider. In this blog post we celebrate the happy conclusion of this incident.
JEP 493 follow-up: install4j 11.0.4 is ready for separate JMOD bundles in Eclipse Temurin 24.0.2
Two months ago, I wrote about how JEP 493 threatened cross-platform JRE bundle creation by allowing JDK vendors to omit JMOD files from their distributions. Without JMOD files, tools like install4j cannot build cross-platform runtime images. This had the potential to seriously disrupt functionality for our users.
Caching auto-provisioned install4j distributions in CI pipelines
Starting with install4j 11.0, integrating install4j into your build system has become much easier: The Gradle, Maven, and Ant plugins can now auto-provision the install4j distribution. This means the plugins will download and cache the appropriate install4j version automatically, so you no longer need to install install4j manually.
Cross-platform JRE bundle creation under threat from JEP 493
One of the most valuable capabilities introduced with the Java module system in Java 9 is its support for creating custom runtime
images with jlink. Developers can include only the modules they need, resulting in lightweight JRE bundles tailored to the
requirements of their applications. Using the --module-path option, it has even been possible to generate those runtime
images for different operating systems from a single host machine.
With Java 24, JEP 493 introduces a change that significantly impacts this workflow.
JDK vendors can now configure builds without .jmod files, as jlink can optionally extract the required resources
from the lib/modules jimage file. While this change reduces the size of the JDK by about 25%, it also removes critical support
for cross-platform linking.
Improvements for macOS App Store submissions in install4j 11.0.2
install4j 11.0.2 introduces several new features to simplify macOS App Store submissions, including automated entitlement handling for TestFlight, improved support for local testing with development provisioning profiles, and dynamic bundle versioning for easier resubmission of builds.
Migrating to install4j 11
In most cases, migrating to install4j 11 usually just involves opening and saving your project with the install4j 11 IDE. Nevertheless, there are some considerations with respect to backward compatibility and some behavioral changes.
Namespace awareness of XML actions in install4j
This post explains an exceptional backward-incompatibility in the install4j 10.0.9 release. This was necessary due to a change in install4j 10.0.8 that was intended to fix the corruption of namespaced XML documents by modifying XML actions.