docs-buildpacks/java/java-native-image.html.md.erb at master · cloudfoundry/docs-buildpacks · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
---
title: Using Java Native Image in Cloud Foundry
owner: Java
---

You  can build your Java apps with native image support and deploy those apps to Cloud Foundry.

A growing number of Java users are building Java apps using support for native images.
For more information, see [Native Image](https://www.graalvm.org/reference-manual/native-image/) in the GraalVM documentation.

Java users deploying to Cloud Foundry can deploy apps compiled using native image support.
However, the Cloud Foundry Java buildpack does not provide support to build, compile, and turn apps into a native image.
You must perform those steps before deploying to Cloud Foundry.

To build an app to run on Cloud Foundry, use native build tools as described below.

## <a id="native-build-tools"></a>Building using Native Build Tools

This section describes how to deploy a Java app with native image support using Native Build Tools.
If you do not want to build using Cloud Native Buildpacks, you can build and compile directly using the Native Build Tools.

To build a Java app using Native Build Tools:

1. Obtain an Ubuntu Bionic computer, VM, or container.
Ubuntu Bionic is recommended for best compatibility with the Cloud Foundry `cflinuxfs3` root filesystem.
Ubuntu 22.04 LTS (Jammy Jellyfish) is recommended for use with `cflinuxfs4`.

2. Install GraalVM. See [Get Started with GraalVM](https://www.graalvm.org/docs/getting-started/).

1. Install the Java Native Image tools. See [Install Native Image](https://www.graalvm.org/reference-manual/native-image/#install-native-image).

3. To add the Native Build Tools to your Maven or Gradle project, follow the instructions in [Add the native build tools plugin](https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/#_add_the_native_build_tools_plugin) in the Spring documentation. This only needs to be done once.

1. Clone the example repository from GitHub:

    ```bash
    git clone https://github.com/paketo-buildpacks/samples
    cd samples/java/native-image/java-native-image-sample
    ```

2. Build the example image:

    ```bash
    mvn -Pnative -DskipTests package
    ```

For more information about building with Native Build Tools, see [Getting started with native build tools](https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/#getting-started-native-build-tools) in the Spring documentation.

### <a id="direct-build"></a>Deploying with direct build

This section describes how to deploy a Java app with native image support using a direct build.

To deploy a Java app with native image support using the binary buildpack:

1. Zip the executable created by your build tool, either Maven or Gradle.
For example, with Maven, `zip demo.zip target/demo`.
Alternatively, you can copy the executable into a directory by itself.
For example, with Maven, `mkdir -p ./out && cp target/demo ./out/`.
This is the root for `cf push`.

2. Push the root ZIP file or directory you created in the previous step.
If you use a directory instead of a ZIP archive, adjust the `-p` argument.
This is important so that it only uploads the compiled binary, not your entire project.
You can adjust other properties or use a `manifest.yml` file to deploy as well.

    ```console
    cf push -b binary_buildpack -p demo.zip -c ./target/demo native-image
    ```

## <a id="spring-boot"></a>Spring Boot and Spring Native

Regardless of how you build your app, with Spring Boot v2.5 and Spring Native v0.10.1, there is a bug that causes `cf push` to fail.
The problem is caused by conditional behavior in Spring Boot Actuator when run on <%= vars.app_runtime_abbr %>. It is fixed in Spring Native v0.10.2.

For more information, see the [spring-projects-experimental](https://github.com/spring-projects-experimental/spring-native/issues/870) repository on GitHub.

You can also work around this issue by adding the following hints above your `@SpringBootapp` annotation:

For example:

```java
@NativeHint(trigger = Reactive<%= vars.app_runtime_abbr %>ActuatorAutoConfiguration.class, types = {
        @TypeHint(types = Endpoint<%= vars.app_runtime_abbr %>Extension.class, access = AccessBits.ANNOTATION),
        @TypeHint(typeNames = "org.springframework.boot.actuate.autoconfigure.<%= vars.app_runtime_abbr %>.<%= vars.app_runtime_abbr %>EndpointFilter"),
        @TypeHint(typeNames = "org.springframework.boot.actuate.autoconfigure.<%= vars.app_runtime_abbr %>.reactive.<%= vars.app_runtime_abbr %>WebFluxEndpointHandlerMapping$<%= vars.app_runtime_abbr %>LinksHandler", access = AccessBits.LOAD_AND_CONSTRUCT
                | AccessBits.DECLARED_METHODS) })
@NativeHint(trigger = <%= vars.app_runtime_abbr %>ActuatorAutoConfiguration.class, types = {
        @TypeHint(types = Endpoint<%= vars.app_runtime_abbr %>Extension.class, access = AccessBits.ANNOTATION),
        @TypeHint(typeNames = "org.springframework.boot.actuate.autoconfigure.<%= vars.app_runtime_abbr %>.<%= vars.app_runtime_abbr %>EndpointFilter"),
        @TypeHint(typeNames = "org.springframework.boot.actuate.autoconfigure.<%= vars.app_runtime_abbr %>.servlet.<%= vars.app_runtime_abbr %>WebEndpointServletHandlerMapping$<%= vars.app_runtime_abbr %>LinksHandler", access = AccessBits.LOAD_AND_CONSTRUCT
                | AccessBits.DECLARED_METHODS) })
@SpringBootapp
public class Demoapp {

    public static void main(String[] args) {
        Springapp.run(Demoapp.class, args);
    }

}
```