[SPR-16991] Support GraalVM native images (Substrate VM) Created: 02/Jul/18  Updated: 09/Aug/18

Status: In Progress
Project: Spring Framework
Component/s: Core
Affects Version/s: None
Fix Version/s: 5.1 RC3

Type: New Feature Priority: Major
Reporter: Sébastien Deleuze Assignee: Sébastien Deleuze
Resolution: Unresolved Votes: 17
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-17014 Make DefaultListableBeanFactory's jav... Closed
Days since last comment: 3 weeks, 2 days ago
Last commented by a User: true
Last updater: Juergen Hoeller


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):

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.

Generated at Mon Aug 20 04:31:49 UTC 2018 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.