Official Google Support for GraalVM compilation

[dzou]

Hello!

My name is Dan and I'm one of the engineers looking into getting GraalVM compilation working for Java Google Client Libraries, across different frameworks like Quarkus, Spring, Micronaut, etc. I was excited to see that you were pursuing an effort here for Quarkus and wanted to give you a heads-up on our work. Perhaps the work we've done so far can help you or vice versa.

We started a project very recently here: https://github.com/GoogleCloudPlatform/google-cloud-graalvm-support

We recently were able to get a Quarkus app working here for the Pub/Sub libraries; you might find this interesting: https://github.com/GoogleCloudPlatform/google-cloud-graalvm-support/tree/master/google-cloud-graalvm-samples/quarkus-pubsub-sample

Our goal for Quarkus is to allow the user to enable compilation just by adding these deps:

    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-grpc</artifactId>
    </dependency>

    <!-- this is the dep we are providing -->
    <dependency>
      <groupId>com.google.cloud</groupId>
      <artifactId>google-cloud-graalvm-support</artifactId>
    </dependency>

I saw we actually had the same approach for some things so far; one example is in the Storage APIs where we saw that you registered the subclasses of some parent classes for reflection recursively; we did the same thing! We are slowly in the process of building reflection configs for different libraries (I think you are ahead of us). However, if you are interested, we would be willing to explore if it's possible to combine our work so we do not duplicate our efforts.

One difference between our work I saw is that we're currently targeting support towards users using the grpc-netty-shaded dependency. I noticed it seemed like you are excluding grpc-netty-shaded and relying on grpc-netty. Indeed we also had some trouble getting grpc-netty-shaded to work for us. However we ended up trying to target grpc-netty-shaded because we thought it would allow users to avoid the dependency exclusion.

Just wanted to say hello and give a heads up!

• Dan

cc/ @meltsufin

[loicmathieu]

Hi dzou ,
It's great news that Google works on GraalVM native support for Google Cloud library.
We can of course works together to avoid duplicated work.

If I understand, you seek for support for all users, it's wonderful, but in this case you cannot rely on Quarkus specific libraries like quarkus-grpc, and gRPC native support wil be the most difficult part I think ;)

As soon as you have native support for some service, we can test it with the quarkiverse-google-cloud-services counterpart, our philosophy in Quarkus is to use the upsteam support if available, and to help build upsteam support of GraalVM native image to allow all possible users/libraries to take advantage of it.

Maybe we can have a chat, we can get in touch in Quarkus Zulip chat or you can contact me by email so we can arrange something next week.

I can already think of multiple enhancements, not necessarily via specific GraalVM support, for example DefaultHttpTransportFactorySubstitution could be refactored to not have a hard dependencies on AppEngine code so the substitution will no longuer be needed. This is the kind of work that can only be done upstream.

Some info you need to know:

• Quarkus gRPC support has been refactored to externalize the native image support in a separate library: quarkus-grpc-common: Extract gRPC common stuff quarkusio/quarkus#12860. This will be available in Quarkus 1.10.
• We cannot use the latests Google Cloud library BOM due to Micrometer using and old Google library: spring data jpa rest apis are broken when micrometer dependencies are added for springboot 1.5.x micrometer-metrics/micrometer#224

[dzou]

Hi Loic,

Thank you for the response. I see, we would be happy to see if we can make some of these upstream changes happen. From how we observed best practices from the Spring team it looked like contributing back code to be native image compatible is often the best practice! We had some success making some code changes to the Netty libraries which went through so I think we can do the same if there are changes needed by some Google Cloud libraries as well.

Sure, we would be happy to chat! I'll reach out to you on Zulip. Many thanks.

Dan

[dzou]

Going to close this after our discussions. Thanks for your time; we'll be in touch!