0

I'm currently trying to run my Spring-Boot/Vaadin V14 app as native executable. It turns out, in general i can translate a Spring-Boot Service or even a Spring-Boot-Data Jpa App into an running executable running outside and inside a Docker container. But it seems not be possible to translate a minimal Spring-Boot/Vaadin V14 App into an native executable.
Repro:
First get sure you have installed successfully the following Tools:
Maven, GraalVM CE Edition (21.1.0) for Java 11, Docker
If you running behind a proxy, it is a good idea to have a local installation of NodeJs for NPM
And be sure you have enough RAM (16 GB or better is a good start).
Next goto: https://start.spring.io
Setup a Maven / Java Spring-boot App with Java 11, Spring-boot 2.5.1 as Jar-File. Add the Dependencies: Spring-Native and Vaadin to it. As a result you get a minimum project setup for Spring-Boot and Vaadin.
Next, if your run the cmd:
mvn -v
it should return something like:
Java version: 11.0.11, vendor: GraalVM Community, runtime: graalvm-ce-java11-21.1.0
or better
Be sure to have Docker up and running and you should have a proper Proxy Setup if you have no direct access to the internet.

Normal compile and running the Vaadin app is done by the cmd:
mvn -Pproduction clean package
after that the resulting fat jar should be at ./target/'appname'.jar
and if so, it can be started with: java -jar target/'appname'.jar
But it doesn't. It continues with native build and fails.

Running the same with the following cmd-line:

mvn -Pnative clean package

Fails too, interestingly with the same errorline:
Failed to execute goal org.springframework.experimental:spring-aot-maven-plugin:0.10.0:test-generate (test-generate) on project demo: Build failed during Spring AOT test code generation: ERROR: in 'com.vaadin.flow.spring.VaadinServletConfiguration' these methods are directly invoking methods marked @Bean: [vaadinRootMapping] - due to the enforced proxyBeanMethods=false for components in a native-image, please consider refactoring to use instance injection. If you are confident this is not going to affect your application, you may turn this check off using -Dspring.native.verify=false. -> [Help 1]

Expected:
A (as usual) long compilation-run with a resulting binary of the application

I tried several variations for a possible fix. E.g. add -Dspring-native.verify=false to the cmd-line, or adding "proxyBeanMethods=false" to the @SpringBootApplication anotation. But it comes always back with the error message.

Looking at the error message it looks quite clear, that this is a implementation flaw in the Vaadin library. If someone knows how to get around this it would be great to know. A possible other way would be some fixing from Vaadin for this.
But it may also be possible that I'm on the wrong track and just simply overlooked something here. Any comment, solution or suggestion are welcome
Ralf Griggel

1 Answers1

0

As far as I know, Vaadin does not support native compilation using GraalVM.

It has recently been brought up in the context of Quarkus. There is a customer-sponsored Vaadin + Quarkus example project on GitHub. This does not yet support native compilation.

There is also this GitHub issue for official Quarkus support. It mentions native compilation using GraalVM under Optional parts/Later additions.

Erik Lumme
  • 5,202
  • 13
  • 27
  • https://github.com/vaadin/base-starter-flow-quarkus has a native-image branch that works for the trivial hello-world application. It is a bit behind on the versions, currently. – jon martin solaas Oct 28 '22 at 11:47