- Why GraalVM?
- Getting Started
- Container Images
- Reference Manuals
- Debugging and Monitoring Tools
- GraalVM as a Platform
- Security Guide
- Release Notes
- Version Roadmap
- GraalVM 21.2.x
- GraalVM 21.1.x
- GraalVM 21.0.x
- GraalVM 20.3.x
- GraalVM 20.2.x
- GraalVM 20.1.x
- GraalVM 20.0.x
- GraalVM 19.3.x
- GraalVM 19.2.x
- GraalVM 19.1.x
- GraalVM 19.0.x
- Release Candidates
- Known Issues
This is a bug fix release for 19.0 and we recommend upgrading for all 19.0.x users.
- Improved compilation performance of scheduler phase.
- Support retrieving annotations from class initializers (see 1320).
- Fixed problems related to the freetype library: 1269, 1270, 1305.
- Fixed Version string reporting (it was missing
64-Bitin the string).
Native image #
IllegalArgumentException: Cannot create Method for class initializer(see 1320).
- Fixed an issue when the build would loop forever if
- Fixed the issue where fallback image generation would not respect the
LLVM interpreter #
Allow LLVM interpreter Context to run without
Early Adopter Windows Support #
The early adopter builds for Windows are available for GraalVM. These include
the JDK with the GraalVM compiler enabled, the Native Image capabilities,
debugger, Profiler etc.. Currently there is no
gu utility or the ability to
add support for the other GraalVM languages.
- We updated the base JDK to 8u212. You can find the JDK release notes at the Oracle Technology Network website.
Native Image #
Native Image was extracted from the base GraalVM distribution. Currently it is
available as an early adopter plugin. To install it, run:
native-image. After this additional step, the
native-image executable will be
bin directory, as for the previous releases.
There was a change in how classes are initialized in a
native-image. Now, we initialize application classes at run time by default. The policy for initialization is as follows:
- All JDK classes are initialized at build time.
- We prove the safety of application static initializers after the analysis and initialize the safe classes.
- We provide the following flags to control class initialization in a fine-grained way:
The performance and startup impact of this change is negligible on all benchmarks that we have.
This change was made to improve user experience: there is no need to write substitutions and to deal with instances of unsupported classes ending up in the image heap. Their applications, given the right configuration for reflection, proxies, etc., should work without performance degradation.
To allow framework authors and end users to keep the startup time at minimum we
improved functionality of
--initialize-at-run-time. These flags allow to specify a policy for whole
packages or individual classes. For example, if we have classes
p.Cn, we can eagerly initialize this package with
--initalize-at-build-time=p. If we want to delay one of the classes in package
p we can simply add
The whole class hierarchy can be initialized at build time by simply passing
--initalize-at-build-time on the command line.
We also introduced the flag
-H:+PrintClassInitialization which allows you to track what class initialization does during the image build. This flag will help you configure the build to work as intended.
What should I do if I am a library author?
- To get your tests back in check you can use
--intialize-at-build-timewhich will revert to the previous behaviour.
- Then use the flag
-H:+PrintClassInitializationto see when classes get initialized. Based on this output you can make the proper configuration.
- Configure your
- Submit a pull request to the downstream libraries with the configuration you believe works well. That way your
native-image.propertieswill be concerned only with the classes from your framework.
- There is a known issue with lambdas being initialized at build time. If your lambda inherits an interface with a default method and static fields, those fields will get pulled into the image. We will provide a fix to this bug in the next two weeks.
- Fixed various bugs that address compilation problems.
- Fixed a fatal error on Linux platforms when sending
SIGINTduring long computations.
- Fixed issues with the installation to protected locations: the default Renviron file sets the
R_LIBS_USERto a directory inside the current user’s home. Users still have to create this directory manually. Alternatively, the
configure_fastrscript creates the directory, but for the current user only.
- Implemented missing C API:
- Various bug fixes. Most notably fixes around OpenSSL C extension compilation.
- Renamed methods in the
Ideal Graph Visualizer (IGV) #
- Fixed the issue with the ASTs and call trees not showing up.