[SPR-16991] Initial GraalVM native images (Substrate VM) support Created: 02/Jul/18  Updated: 15/Jan/19  Resolved: 10/Sep/18

Status: Closed
Project: Spring Framework
Component/s: Core
Affects Version/s: None
Fix Version/s: 5.1 GA

Type: New Feature Priority: Major
Reporter: Sébastien Deleuze Assignee: Sébastien Deleuze
Resolution: Complete Votes: 22
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
depends on SPR-17007 RestTemplate (and probably server sid... Closed
depends on SPR-16992 Support platforms where Class is not ... Closed
depends on SPR-17000 Perform explicit class checks in Reac... Closed
depends on SPR-17005 DefaultParameterNameDiscoverer should... Closed
depends on SPR-17136 Detect GraalVM with system property i... Closed
depends on SPR-17198 Be more defensive in UrlResource abou... Closed
depends on SPR-17253 Usage of ClassLoader.loadClass() in C... Closed
depends on SPR-17014 Make DefaultListableBeanFactory's jav... Closed
Days since last comment: 18 weeks, 6 days ago
Last commented by a User: true
Last updater: Spring Issuemaster


We have began to work with Dave Syer on improving support for running Spring Framework based application as native images via Substrate VM from GraalVM project.

Oracle is currently working on improving support for Spring based on our feedback, so this issue is mainly intended to track those efforts, but also to track fine tuning we could do to improve Spring Framework support for such platform.

Since Spring relies on reflection and proxies, these documents are worth to read:

It has been possible to run a minimal WebFlux.fn + Netty application successfully using functional bean registration, see this Spring Fu issue for more details. Startup time as native image is very fast (30 ms). The self-sufficient executable size is 50 MB and the resident memory is 35 MB.

In parallel to this work, we are also trying to get regular Spring Framework / Boot applications working and to identify how much configuration will be needed (for now we generate it manually). Latest pending issue is being able to run ConversionService, see graal#507 for more details.

Comment by Sébastien Deleuze [ 03/Jul/18 ]

We are doing good progress. With SPR-16992 and SPR-17000 fixed + using GraalVM master, we have been able to go pretty far with a Jetty version of spring-boot-micro-apps.
Current blocking error is a UnsupportedFeatureError: Unresolved element found thrown when processing org.springframework.boot.web.reactive.error.ErrorWebExceptionHandler.
Even with custom configuration, error remains so Dave Syer has raised an issue on GraalVM side about that.

Juergen Hoeller Something that looks interesting to me, especially in Spring context, is RuntimeReflection.register() API that could allow Spring Framework to inform GraalVM AOT compiler about the classes it instantiates reflectively, or even about the ones instantiated by the dependencies we integrate (Netty, Jetty, Log4j).

class RuntimeReflectionRegistrationFeature implements Feature {
  public void beforeAnalysis(BeforeAnalysisAccess access) {
    try {
      RuntimeReflection.register(String.class.getDeclaredMethod("charAt", int.class));
      RuntimeReflection.register(String.class.getDeclaredMethod("format", String.class, Object[].class));
      RuntimeReflection.register(String.CaseInsensitiveComparator.class.getDeclaredMethod("compare", String.class, String.class));
    } catch (NoSuchMethodException | NoSuchFieldException e) { ... }
Comment by Sébastien Deleuze [ 05/Jul/18 ]

For the record, here is the list of the pending GraalVM issues related to Spring (mostly raised by Dave Syer, kudos to him):


Workaround proposed


Norman Maurer also fixed this Netty issue on GraalVM we raised.

Comment by Sébastien Deleuze [ 27/Jul/18 ]

Very interesting changes in GraalVM: native-image reflection support by automatically detecting reflective calls and intrinsifying them to the corresponding target elements statically.

Comment by Sébastien Deleuze [ 05/Sep/18 ]

I have updated the status of the pending issues, we make progress but we are currently blocked by this GraalVM 1.0.0-rc6 regression.

Comment by Sébastien Deleuze [ 06/Sep/18 ]

I have created spring-boot-graal-demo that will be used by GraalVM team to avoid regression on their side and for us to create branches demonstrating each issue.

Comment by Sébastien Deleuze [ 10/Sep/18 ]

I think we can consider initial support finished from a Spring Framework 5.1 perpective for now since most remaining issues are on GraalVM side. We will continue to collaborate with GraalVM team to provide repro projects and create issues.

The first step to reach will be to get Spring functional application supported. The second milestone step will be to get JavaConfig supported. The third step will be to get GraalVM supported on Spring Boot side.

We will fix remaining issues as part of Spring Framework 5.1.x or 5.2 releases.

Comment by Spring Issuemaster [ 14/Jan/19 ]

The Spring Framework has migrated to GitHub Issues. This issue corresponds to spring-projects/spring-framework#21529.

Generated at Mon May 27 03:37:02 UTC 2019 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.