- Native Image
- Build Configuration
- Native Image Compatibility and Optimization Guide
- Class Initialization in Native Image
- Static Native Images
- Native Image Options
- Native Image Hosted and Runtime Options
- Native Image C API
- Implementing Native Methods in Java with Native Image
- LLVM Backend for Native Image
- Debug Info Feature
- Points-to Analysis Reports
- Using System Properties in Native Images
- Profile-Guided Optimizations
- Memory Management at Image Run Time
- Generating Heap Dumps from Native Images
- Native Image Maven Plugin
- JCA Security Services on Native Image
- Dynamic Proxy on Native Image
- Java Native Interface (JNI) on Native Image
- Reflection on Native Image
- Accessing Resources in Native Images
- Logging on Native Image
- URL Protocols on Native Image
- GraalVM Updater
- Embedding Reference
- Polyglot Programming
- Java Reference
- Java on Truffle
- LLVM Languages Reference
- Python Reference
- Ruby Reference
- R Reference Manual
- WebAssembly Reference
JCA Security Services in Native Image
The JCA framework uses a provider architecture to access security services such as digital signatures, message digests, certificates and certificate validation, encryption (symmetric/asymmetric block/stream ciphers), key generation and management, and secure random number generation, etc. To achieve algorithm independence and extensibility it relies on reflection, therefore it requires a custom configuration in Native Image. The Native Image builder uses static analysis to discover which of these services are used.
Each provider registers concrete implementation classes for the algorithms it supports.
Each of the service classes (
KeyStore, etc.,) declares a series of
getInstance(<algorithm>, <provider>) factory methods which provide a concrete service implementation.
When a specific algorithm is requested the framework searches the registered providers for the corresponding implementation classes and it dynamically allocates objects for concrete service implementations.
The Native Image builder uses static analysis to discover which of these services are used.
It does so by registering reachability handlers for each of the
getInstance() factory methods.
When it determines that a
getInstance() method is reachable at run time it automatically performs the reflection registration for all the concrete implementations of the corresponding service type.
This mechanism is implemented in the
The simplest images contain support for the
MessageDigest engines from the
These are core security services needed by the VM itself.
--enable-all-security-services option is now deprecated and it will be removed in a future release.
Provider Registration #
The native image builder captures the list of providers and their preference order from the underlying JVM.
The provider order is specified in the
java.security file under
New security providers cannot be registered at run time; all providers must be statically configured during a native image building.
The SecureRandom implementations open the
/dev/urandom files which are used as sources for entropy.
These files are usually opened in class initializers.
To avoid capturing state from the machine that runs the Native Image builder these classes need to be initialized at run time.