Spring Native: Going Native with JHipster and Spring Boot

Author

Known Issues

Before proceeding any further it would be opportune to first point out the features of the JHipster application that we were not able to make work in the native image build of Geodata application.

1. Cache

In this run, we haven’t managed to figure out how to make ehcache work with Spring Native build. There is an ongoing thread on spring-experimental project forum on this topic, and it seems that at the moment neither ehcache nor caffein are supported.

2. EntityGraph

For some reasons EntityGraph annotation on User entity is not working.

3. Logs endpoint (/management/loggers)

This endpoint returns HTML instead of JSON?

4. Configuration endpoint (/management/configprops)

Calls to this endpoint result in the following error:

org.springframework.http.converter.HttpMessageNotWritableException: No converter for [class org.springframework.boot.actuate.context.properties.ConfigurationPropertiesReportEndpoint$ApplicationConfigurationProperties] with preset Content-Type ‘null’)

5. Mockito is not supported

Mockito is not supported (there is a blocked issue with more info concerning this topic: https://github.com/spring-projects-experimental/spring-native/issues/1063) so all mockito tests in the project can not be run.

Building native image of Geodata Rest API

To be able to follow this blog post hands on, you need to have the following tools installed on your workstation:

Git client
Java SDK 11
Docker client
IDE of your choice (IntelliJ, VS Code, Eclipse …)

Start by cloning geodata-rest-sb repository:

git clone git@github.com:dmadunic/geodata-sb-rest.git

Now cd to the geodata-rest-sb folder and build the classic docker app image:

cd geodata-rest-sb/
./gradlew bootJar -Pprod jibDockerBuild -PimageVersion=latest

This will build “ag04/geodata-rest-sb:latest” docker image in your local docker repository.

domagoj@dm-tuxXP14G14:~$ docker images
REPOSITORY                                 TAG             IMAGE ID       CREATED         SIZE
ag04/geodata-rest-sb                       latest          b14bb3a6a517   17 seconds ago  339MB

Application can now be run with the use of the prepared docker-compose yaml file:

docker-compose -f src/main/docker/app.yml up

This will download all necessary images and once this is done start up all the services: Geodata-rest API, nginx server with Geodata Angular frontend and PostgreSQL database (available on localhost port 5433). Startup time of the geodata rest API varies and depends on the configuration of your workstation, on mine it usually takes around 15 seconds.

Note down this value we will compare it later with the startup time of the native image rest api build. If you point your browser to: “http://localhost:9000/” you should be greeted with the GeodataApp welcome screen. You can sign in using default jhipster username and credentials of user/user and admin/admin.

To shutdown geodata services execute the following command:

docker-compose -f src/main/docker/app.yml down

Finally, import the Geodata Rest API to your favorite IDE (Idea, IntelliJ,…) and we can start adjusting the app for native build. In the following sections we will provide detailed instructions on steps we have undertaken to achieve the build of the working native image of Geodata Rest API application.

Configuring gradle build configuration files

To build native image of the Spring Boot app we need Spring AOT Engine, and since geodata-rest-sb is an application built with gradle therefore the first thing we need to do is to register Spring AOT gradle plugin. Thus, we need to change setting.gradle to look as shown below:

pluginManagement {
    repositories {
       //maven { url 'https://repo.spring.io/milestone' }
       gradlePluginPortal()
       maven { url 'https://repo.spring.io/release' }
   }
   plugins {
       id 'org.springframework.boot' version "${springBootVersion}"
       id 'com.google.cloud.tools.jib' version "${jibPluginVersion}"
       id 'com.gorylenko.gradle-git-properties' version "${gitPropertiesPluginVersion}"
       id 'org.liquibase.gradle' version "${liquibasePluginVersion}"
       id 'org.sonarqube' version "${sonarqubePluginVersion}"
       id "io.spring.nohttp" version "${noHttpCheckstyleVersion}"
       id 'com.github.andygoossens.gradle-modernizer-plugin' version "${modernizerPluginVersion}"
       id 'org.springframework.experimental.aot' version "${springAotPlugin}"
   }
}
rootProject.name = "geodata-rest-sb"

What we have done is: 1) commented standard spring milestone repository and instead added spring release repository, and 2) registered spring aot plugin.

The next step is to modify the gradle.properties file. Geodata Rest API is an application generated with jhipster version 7.5.0 and is thus built on Spring Boot version 2.5.8. However, the latest version of spring AOT engine requires Spring Boot 2.6.2, thus we need to adjust some dependency versions, namely increase versions of Spring Boot to 2.6.2 and Hibernate to 5.6.3.Final. Change the “Dependency versions” section of the file to match the following snipper:

# Dependency versions
jhipsterDependenciesVersion=7.5.0
# The spring-boot version should match the one managed by
# https://mvnrepository.com/artifact/tech.jhipster/jhipster-dependencies/7.5.0
springBootVersion=2.6.2
#springBootVersion=2.5.8
# The hibernate version should match the one managed by
# https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-dependencies/2.5.8 -->
hibernateVersion=5.6.3.Final
#hibernateVersion=5.4.33
…

Additionally, at the end of the “gradle plugin versions” section add the version for spring AOT gradle plugin:

# gradle plugin version
jibPluginVersion=3.1.4
gitPropertiesPluginVersion=2.3.2
liquibasePluginVersion=2.1.1
sonarqubePluginVersion=3.3
noHttpCheckstyleVersion=0.0.10
checkstyleVersion=9.2
modernizerPluginVersion=1.6.1
springAotPlugin=0.11.1

With these changes in place, we can now switch to modifying build.gradle. The first thing we need to do is to modify buildscript section and replace milestone repository with the release one. Second, in the buildscript.dependencies section we need to register a hibernate-gradle-plugin which is needed for bytecode build time enhancement (to allow for features such as Lazy loading). Finally add the spring aot gradle plugin to the list of registered plugins. The next code snippet displays all the changes done:

buildscript {
   repositories {
       gradlePluginPortal()
       maven { url 'https://repo.spring.io/release' }
   }
   dependencies {
       //jhipster-needle-gradle-buildscript-dependency - JHipster will add additional gradle build script plugins here
       classpath "org.hibernate:hibernate-gradle-plugin:5.6.3.Final"
   }
}
 
plugins {
   id "java"
   ...
   //jhipster-needle-gradle-plugins - JHipster will add additional gradle plugins here
   id "org.springframework.experimental.aot"
}
apply plugin: 'org.hibernate.orm'

For hibernate enhancement plugin to be active, add the following block of configuration just above defaultTask declaration.

hibernate {
   enhance {
       enableLazyInitialization= true
       enableDirtyTracking = true
       enableAssociationManagement = true
       enableExtendedEnhancement = false
   }
}
defaultTasks "bootRun"

Next change we need to do is to comment springBoot section and specify some native build parameters, as shown here:

/*
springBoot {
    mainClassName = "com.ag04.geodata.GeodataRestSbApp"
}
*/
 
bootBuildImage {
    imageName = "ag04/geodata-rest-sb-native"
    builder = "paketobuildpacks/builder:tiny"
    environment = [
        "BP_NATIVE_IMAGE" : "true"
    ]
}

In this configuration block, we specify Paketo Buildpacks as target builder of our native image and a custom image name of “ag04/geodata-rest-sb-native” as our build target.

Also, in the repositories section, we need to change spring milestone repository with the release one, as is shown below:

repositories {
   // Local maven repository is required for libraries built locally with maven like development jhipster-bom.
   // mavenLocal()
   mavenCentral()
   //jhipster-needle-gradle-repositories - JHipster will add additional repositories
   maven { url 'https://repo.spring.io/release' }
}

At the moment spring devtools are not supported in native builds so we need to disable them. Change the configuration section of the build.gradle to look as follows:

configurations {
   providedRuntime
   //implementation.exclude module: "spring-boot-starter-tomcat"
   all {
       exclude group:"org.springframework.boot", module: "spring-boot-devtools"
       resolutionStrategy {
           // Inherited version from Spring Boot can't be used because of regressions:
           // To be removed as soon as spring-boot use the same version
           force 'org.liquibase:liquibase-core:4.6.1'
       }
   }
}

In this section we have also commented out the “spring-boot-starter-tomcat” exclusion, since we will need this dependency.

With this done we have finished changing projects’ configuration files, and we can proceed to the next step, that is configuring correct project dependencies.

Configure project dependencies

Since we are using gradle, we do not need to add the spring-native dependency manually, the Spring AOT plugin will add it automatically for us. However, we still need to do a considerable number of changes in the dependencies section of build configuration.

Set explicit version for all spring dependencies

In order to avoid collision with the jhipster specified dependencies, we need to manually specify versions for ALL of the spring libraries we are using in the project. As is, for example, shown here in the the following configuration block:

implementation "org.springframework.boot:spring-boot-loader-tools:${springBootVersion}"
implementation "org.springframework.boot:spring-boot-starter-mail:${springBootVersion}"
implementation "org.springframework.boot:spring-boot-starter-logging:${springBootVersion}"
implementation "org.springframework.boot:spring-boot-starter-actuator:${springBootVersion}"
implementation "org.springframework.boot:spring-boot-starter-data-jpa:${springBootVersion}"

Explicitly add dependency for spring-boot-starter-validation

implementation "org.springframework.boot:spring-boot-starter-validation:${springBootVersion}"

If we do not add this, the version of the library specified by jhipster BOM would be used, and not the one we specified in gradle.properties.

Explicitly set hibernate version

Similar as in the case of the spring dependencies we need to manually set versions for the following hibernate dependencies:

implementation "org.hibernate:hibernate-core:${hibernateVersion}"
implementation "org.hibernate:hibernate-entitymanager:${hibernateVersion}"
liquibaseRuntime "org.liquibase.ext:liquibase-hibernate5:${liquibaseHibernate5Version}"

Replace undertow with tomcat

Locate the following block of configuration in the build.gradle:

implementation ("org.springframework.boot:spring-boot-starter-web") {
   exclude module: "spring-boot-starter-tomcat"
}
implementation "org.springframework.boot:spring-boot-starter-undertow"

and change it to look as follows:

/*
implementation ("org.springframework.boot:spring-boot-starter-web") {
   exclude module: "spring-boot-starter-tomcat"
}
implementation "org.springframework.boot:spring-boot-starter-undertow"
*/
implementation "org.springframework.boot:spring-boot-starter-web:${springBootVersion}"
implementation "org.springframework.boot:spring-boot-starter-tomcat:${springBootVersion}"

Replace springdoc-openapi-webmvc-core with springdoc-openapi-native

//implementation ("org.springdoc:springdoc-openapi-webmvc-core")
implementation ("org.springdoc:springdoc-openapi-native:1.6.0")

Disable spring-cloud-starter-bootstrap

//implementation "org.springframework.cloud:spring-cloud-starter-bootstrap"

Find the following block of configuration:

if (!project.hasProperty("gae")) {
    runtimeOnly "io.jsonwebtoken:jjwt-impl"
    runtimeOnly "io.jsonwebtoken:jjwt-jackson"
} else {
   implementation "io.jsonwebtoken:jjwt-impl"
   implementation "io.jsonwebtoken:jjwt-jackson"
}

And modify it to look as follows:

implementation "io.jsonwebtoken:jjwt-impl"
runtimeOnly "io.jsonwebtoken:jjwt-jackson"

Remove spring-boot-devtools dependency

//developmentOnly "org.springframework.boot:spring-boot-devtools:${springBootVersion}"

Remove cache dependencies

Since we haven’t been able to make cache to work (bootstrap code generated by AOT is incompatible with the method signatures of the org.springframework.cache.jcache.config.ProxyJCacheConfiguration.java), go ahead and simply comment the following libraries:

//implementation "org.springframework.boot:spring-boot-starter-cache"
//implementation "javax.cache:cache-api"
//implementation "org.ehcache:ehcache"
//implementation "org.hibernate:hibernate-jcache"

Since no cache libraries are available on the application classpath, we also need to disable hibernate second level cache. This is done by setting the following property to false inside application.yml file:

hibernate.cache.use_second_level_cache: false

Fix logging

Based on this discussion from spring native forum, it seems that support for Logback logging library will be available with 0.11.3 version of Spring AOT engine, so for now just delete logback-spring.xml file from the src/main/resources folder.Also I would suggest to reduce the level of output to logs by setting logging properties in application-prod.yml on these lines:

logging:
 level:
   ROOT: INFO
   tech.jhipster: INFO
   com.ag04.geodata: DEBUG
   io.netty: ERROR
   org.springframework: INFO

Next step is to apply several code changes that are necessary for native image of the application to work.

Java code adjustments

The first thing that we need to do is to add necessary hints to main Spring boot class: com.ag04.geodata.GeodataRestSbApp.java

GraalVM relies on these hints for building native image, this is the source of information for the engine concerning how to add classes that are not explicitly used in the code to target build.

Without these hints, for example, Liquibase, Jwt authentication, async processing or thymeleaf engine would not work.

So, go ahead and ad this block of annotations to the main spring boot class:

@TypeHint(
   types = {
       org.HdrHistogram.Histogram.class,
       org.HdrHistogram.ConcurrentHistogram.class,
       liquibase.configuration.LiquibaseConfiguration.class,
       com.zaxxer.hikari.HikariDataSource.class,
       liquibase.change.core.LoadDataColumnConfig.class,
       tech.jhipster.domain.util.FixedPostgreSQL10Dialect.class,
       org.hibernate.type.TextType.class,
       io.jsonwebtoken.impl.DefaultJwtParserBuilder.class,
       io.jsonwebtoken.impl.DefaultJwtBuilder.class,
       java.util.Locale.class,
       com.sun.mail.smtp.SMTPSSLTransport.class,
   }
)
@JdkProxyHint(
   types = {
       org.springframework.data.jpa.repository.support.CrudMethodMetadata.class,
       org.springframework.aop.SpringProxy.class,
       org.springframework.aop.framework.Advised.class,
       org.springframework.core.DecoratingProxy.class,
   }
)
@TypeHint(types = { java.util.Locale.class }, methods = { @MethodHint(name = "getLanguage") })
@SpringBootApplication
@EnableConfigurationProperties({ LiquibaseProperties.class, ApplicationProperties.class })
public class GeodataRestSbApp {
…
}

The next step is to fix Task Executor configuration. Without this fix, the application behaves as if the Spring didn’t invoke the afterPropertiesSet method on the ExceptionHandlingAsyncTaskExecutor – which it does if you enable trace and debug logs in the relevant classes and check the output. Anyhow, the problem is solved by invoking the method manually when creating the bean in the AsyncConfiguration class.

To do so apply the changes from the following snippet to the AsyncConfiguration:

@Override
@Bean(name = "taskExecutor")
public Executor getAsyncExecutor() {
   ...
   //return new ExceptionHandlingAsyncTaskExecutor(executor);
   ExceptionHandlingAsyncTaskExecutor taskExecutor = new ExceptionHandlingAsyncTaskExecutor(executor);
 
   try {
       taskExecutor.afterPropertiesSet();
       return taskExecutor;
   } catch (Exception e) {
       throw new RuntimeException(e);
   }
}

As noted previously, @EntityGraph annotation is not working in the current settings, so we need to comment this annotation on following methods in the UserRepository.java:

//@EntityGraph(attributePaths = "authorities")
@Cacheable(cacheNames = USERS_BY_LOGIN_CACHE)
Optional<User> findOneWithAuthoritiesByLogin(String login);
 
//@EntityGraph(attributePaths = "authorities")
@Cacheable(cacheNames = USERS_BY_EMAIL_CACHE)
Optional<User> findOneWithAuthoritiesByEmailIgnoreCase(String email);

Also, we need to adjust the authorities property of the User entity (com.ag04.geodata.domain.User.java) to include FetchType.EAGER instruction to JPA (or the DomainUserDetailsService will fail attempting to fetch user during the login), as is shown here:

@JsonIgnore
@ManyToMany(fetch = FetchType.EAGER)
@JoinTable(
name = "jhi_user_authority",
      joinColumns = { @JoinColumn(name = "user_id", referencedColumnName = "id") },
      inverseJoinColumns = { @JoinColumn(name = "authority_name", referencedColumnName = "name") }
   )
   @Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
   @BatchSize(size = 20)
   private Set<Authority> authorities = new HashSet<>();

Fixing support for mail sending required some hacking and workarounds. For mysterious reasons, when running inside native build, spring autoconfiguration for MailSender does not kick in and MailSender is not configured. After some pondering over this issue, we decided to manually configure the Java mail sender, in the same way Spring itself configures JavaMailSender.

Therefore, inside the package com.ag04.geodata.config we added a file MailPropertiesConfiguration.java

package com.ag04.geodata.config;
 
import org.springframework.boot.autoconfigure.mail.MailProperties;
import org.springframework.context.annotation.Configuration;
 
@Configuration
public class MailPropertiesConfiguration extends MailProperties {
}

Now, in the same package also create file MailConfiguration.java with the following content:

@Configuration
public class MailConfiguration {
  
   @Bean
   JavaMailSenderImpl mailSender(MailProperties properties) {
       JavaMailSenderImpl sender = new JavaMailSenderImpl();
       applyProperties(properties, sender);
       return sender;
   }
 
   private void applyProperties(MailProperties properties, JavaMailSenderImpl sender) {
       sender.setHost(properties.getHost());
       if (properties.getPort() != null) {
           sender.setPort(properties.getPort());
       }
       sender.setUsername(properties.getUsername());
       sender.setPassword(properties.getPassword());
       sender.setProtocol(properties.getProtocol());
       if (properties.getDefaultEncoding() != null) {
           sender.setDefaultEncoding(properties.getDefaultEncoding().name());
       }
       if (!properties.getProperties().isEmpty()) {
           sender.setJavaMailProperties(asProperties(properties.getProperties()));
       }
   }
 
   private Properties asProperties(Map<String, String> source) {
       Properties properties = new Properties();
       properties.putAll(source);
       return properties;
   }
}

The above source is basically taken from the spring package. With these last changes in place we are almost done with the adjusting goedata-rest-sb application for native build, and there is one more piece of configuration we need to add.

We also need to clean up a UserService.java, namely to remove all references to the CacheManager class from it (since we do not have a working cache provider at the moment). What needs to be done is to comment private property CacheManager, remove CacheManager from the signature of the constructor (as shown below):

  //private final CacheManager cacheManager;
  
   public UserService(
       UserRepository userRepository,
       AuthorityRepository authorityRepository,
       PasswordEncoder passwordEncoder
   ) {
       this.userRepository = userRepository;
       this.authorityRepository = authorityRepository;
       this.passwordEncoder = passwordEncoder;
   }

and also comment the entire body of the clearUsercaches() method:

private void clearUserCaches(User user) {
       /*  Objects.requireNonNull(cacheManager.getCache(UserRepository.USERS_BY_LOGIN_CACHE)).evict(user.getLogin());
       if (user.getEmail() != null) {  Objects.requireNonNull(cacheManager.getCache(UserRepository.USERS_BY_EMAIL_CACHE)).evict(user.getEmail());
       }*/
}

Finally to avoid compilation errors delete the entire class file: com.ag04.geodata.config.CacheConfiguration.java from the project.

Configuring static resources

The last piece of the puzzle concerns the access to static resources in the native image. Official GraalVM documentation states the following:

“By default, the native image builder will not integrate any of the resources which are on the classpath during the generation into the final image.”

As a result of this, any attempt to access static files located inside jar files available on the classpath will fail! In the case of our application this means that in the native image, liquibase will not be working, since it needs access to the XSD files, or that JavaMailSender will not be able to be initialized because it will fail to access several files from jakarta-mail.jar.

To overcome this we need to instruct GraalVM to include these files in our build. We can do that by defining which static files to be included (or excluded) in the file named: resource-config.json, located in the folder src/main/resources/META-INF/native-image/. GraalVM will automatically detect any such files and apply them. Further customization is also available with the spring-native hints as documented here.

Therefore go ahead and create this file with the following content:

{
   "resources": {
       "includes": [
           {"pattern" : "\\Qorg/springframework/mail/javamail/mime.types\\E"},
           {"pattern" : ".*/javamail.default.address.map"},
           {"pattern" : ".*/javamail.default.providers"},
           {"pattern" : ".*/javamail.charset.map"}
       ]
   }
}

This solves all the Java Mail Sender initialization problems, what remains to be tackled is the problem of including all of liquibase XSD files. Fortunately, there is a Pull Request that provides solutions to this problem. Take the two files from this PR (resource-config.json and reflect-config.json) and save them to “src/main/resources/META-INF/native-image/liquibase/” folder.

Finally, it is time to build native image of the Geodata Rest API.

Building and running native image

To build native image issue the following command inside root project folder:

./gradlew clean bootBuildImage

This will start a build, be patient since building native images takes considerably longer time than building a normal one.

Once the build is done, you can check if image is available in you local docker registry:

docker images

And in the list of the local container images you should now also see “ag04/geodata-rest-sb-native” image:

REPOSITORY                                 TAG             IMAGE ID       CREATED         SIZE
...
ag04/geodata-rest-sb-native                latest          aeb33a851c36   42 years ago    201MB
...

As can be seen, this image is noticeably smaller than the standard one (210Mb vs 313Mb).

In order to use this image open docker-compose file appl.yml we used previously at the beginning of this exercise, and modify geodata-rest-sb service image “name” property to refer to the new native image, as shown here:

geodata-rest-sb:
   image: ag04/geodata-rest-sb-native:latest
   environment:
     - _JAVA_OPTIONS=-Xmx512m -Xms256m

Save the changes and run the application by executing:

docker-compose -f src/main/docker/app.yml up

If all went well you should see the output similar to the one bellow:

geodata-rest-sb_1           | 2022-02-02 19:02:44.576  INFO 1 --- [           main] o.s.b.a.e.web.EndpointLinksResolver      : Exposing 9 endpoint(s) beneath base path '/management'
geodata-rest-sb_1           | 2022-02-02 19:02:44.578  INFO 1 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
geodata-rest-sb_1           | 2022-02-02 19:02:44.578  INFO 1 --- [           main] com.ag04.geodata.GeodataRestSbApp        : Started GeodataRestSbApp in 0.417 seconds (JVM running for 0.418)
geodata-rest-sb_1           | 2022-02-02 19:02:44.579  INFO 1 --- [           main] com.ag04.geodata.GeodataRestSbApp        : 
geodata-rest-sb_1           | ----------------------------------------------------------
geodata-rest-sb_1           | 	Application 'geodataRestSb' is running! Access URLs:
geodata-rest-sb_1           | 	Local: 		http://localhost:8080/
geodata-rest-sb_1           | 	External: 	http://172.25.0.4:8080/
geodata-rest-sb_1           | 	Profile(s): 	[prod, api-docs, awsses]
geodata-rest-sb_1           | ---------------------------------------------------------

In my case, the Geodata Rest API built as native image started up in just 418 ms compared to 15 seconds in the case of the image built in a standard way! Which is really impressive.

Conclusion

Having an understanding of what the native image builder does – shaves off excess classes, methods, resources etc. that it deems unreachable – the task at hand seemed simple: learn and understand ways to pass hints to the builder, then employ those ways to instruct it to leave used code and resources in the final image.

However, this turned out to be all but simple. There are several ways to pass hints, and several layers of abstraction on top of the annotations in org.springframework.nativex.hint package. The docs are so-so, and there was a lot of trial and error going on. Taking into account image build times, this effort was very time consuming.

Furthermore, many exceptions didn’t simply state “this class/method/resource is missing”. What happened instead is that the framework/library got initialized or used the wrong way because internal exceptions sometimes got caught and recovered from, or branching conditions got evaluated differently than in a non-native context. Then, 5 miles down the road something blew up giving you no obvious thing to fix – i.e. hint to employ. Being a detective in the library source and backtracking from the exception you got was a must have skill.

The final jalapeno is that certain code didn’t get invoked until you triggered a certain feature. E.g. sending a mail, doing work in a separate WorkExecutor thread etc. This implies that when you convert your app to a native variant, you’re left with a full feature sweep to do. Sometimes – many times – not a simple feat at all.

Given all that, we hold the opinion that this is still not ready for the mass market. And that’s when taking into account most of the features used here are basic and we didn’t integrate with anything external other than the DB or email server. What we would like though – and what surely is an area many library authors are working on – is to see better native support. Namely

Clearer error messages
Friendlier ways to choose and pass hints to the native image builder

Finally – all the negatives aside – the positives are extremely convincing. Startup time is next to nothing, memory consumption is decreased, as well as the image size – and those alone are big enough reasons to seriously assess this approach.

Closing remarks

By the time we finished this article, new versions of both JHipster (v7.6.0) and Spring AOT plugin (0.11.2) came out. All with dozens of improvements: upgrade of JHipster to Spring Boot 2.6.3. (which is the target working version for Spring AOT 0.11.2 plugin) support for spring devtools, and many more.

However, as great as this sounds, it seems that in the world of native spring images nothing is simple, and in our case this proved to be more of a step back than a step forward. Upgrading to the 0.11.2 version of the Spring AOT plugin introduced a problem of circular dependencies between liquibase bean and dataSourceScriptDatabaseInitializer bean.

A problem that does not exist outside of native build, and we were unable to either solve it or to find a suitable workaround. Moreover, Spring AOT plugin 0.11.1 we used in this example does not work properly with Spring Boot 2.6.3.This problem is deeply rooted in the Spring AOT plugin, and as it stands now we decided to leave things as they are and tackle this issue in some future exercise/blog post.

This latest experience strengthened our opinion that Spring Native is without any doubt very promising technology, and that one should keep close track of it, though its application at the moment should be limited to special cases.

Resources

Fully completed working native build version of the Geodata Rest API is available on “native” branch of the project github repository.

Links

Official spring documentation
(https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/)

GraalVM reference manual
(https://www.graalvm.org/reference-manual/)

Matt Raible Spring Native build examples
(https://github.com/mraible/spring-native-examples)

Cookie	Duration	Description
__cf_bm	30 minutes	This cookie, set by Cloudflare, is used to support Cloudflare Bot Management.
__hssc	30 minutes	HubSpot sets this cookie to keep track of sessions and to determine if HubSpot should increment the session number and timestamps in the __hstc cookie.
bcookie	1 year	LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie	1 year	LinkedIn sets this cookie to store performed actions on the website.
lang	session	LinkedIn sets this cookie to remember a user's language setting.
lidc	1 day	LinkedIn sets the lidc cookie to facilitate data center selection.
UserMatchHistory	1 month	LinkedIn sets this cookie for LinkedIn Ads ID syncing.

Cookie	Duration	Description
__hstc	5 months 27 days	This is the main cookie set by Hubspot, for tracking visitors. It contains the domain, initial timestamp (first visit), last timestamp (last visit), current timestamp (this visit), and session number (increments for each subsequent session).
_ga	2 years	The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.
_ga_3J4RG7DPVC	2 years	This cookie is installed by Google Analytics.
_gat_gtag_UA_146577527_1	1 minute	Set by Google to distinguish users.
_gat_gtag_UA_243579083_1	1 minute	Set by Google to distinguish users.
_gcl_au	3 months	Provided by Google Tag Manager to experiment advertisement efficiency of websites using their services.
_gid	1 day	Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.
_hjAbsoluteSessionInProgress	30 minutes	Hotjar sets this cookie to detect the first pageview session of a user. This is a True/False flag set by the cookie.
_hjFirstSeen	30 minutes	Hotjar sets this cookie to identify a new user’s first session. It stores a true/false value, indicating whether it was the first time Hotjar saw this user.
_hjIncludedInPageviewSample	2 minutes	Hotjar sets this cookie to know whether a user is included in the data sampling defined by the site's pageview limit.
_hjIncludedInSessionSample	2 minutes	Hotjar sets this cookie to know whether a user is included in the data sampling defined by the site's daily session limit.
CONSENT	2 years	YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
hubspotutk	5 months 27 days	HubSpot sets this cookie to keep track of the visitors to the website. This cookie is passed to HubSpot on form submission and used when deduplicating contacts.
ln_or	1 day	Linkedin sets this cookie to registers statistical data on users' behaviour on the website for internal analytics.

Cookie	Duration	Description
_fbp	3 months	This cookie is set by Facebook to display advertisements when either on Facebook or on a digital platform powered by Facebook advertising, after visiting the website.
_rdt_uuid	3 months	Reddit sets this cookie to build a profile of your interests and show you relevant ads.
fr	3 months	Facebook sets this cookie to show relevant advertisements to users by tracking user behaviour across the web, on sites that have Facebook pixel or Facebook social plugin.
test_cookie	15 minutes	The test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies.
VISITOR_INFO1_LIVE	5 months 27 days	A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC	session	YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.

Cookie	Duration	Description
_fw_crm_v	1 year	No description available.
_hjSession_3179770	30 minutes	No description
_hjSessionUser_3179770	1 year	No description
AnalyticsSyncHistory	1 month	No description
DEVICE_INFO	5 months 27 days	No description
first_session	1 month 1 day	No description available.
li_gc	5 months 27 days	No description
test	never	No description available.
theme	never	No description available.
zarget_user_id	1 year	No description available.

Spring Native: Going Native with JHipster and Spring Boot

Known Issues

Building native image of Geodata Rest API

Configuring gradle build configuration files

Configure project dependencies

Fix logging

Java code adjustments

Configuring static resources

Building and running native image

Conclusion

Closing remarks

Resources

Links

Next

Notch Talks: A Senior’s Perspective

Our people really love it here

Evolution of expertise

Personal development

We’d love to hear from you