<div dir="ltr">Hello all!<div><br></div><div>I'm currently investigating building midPoint as a native-bytecode application running directly under the OS without a Java Virtual Machine layer. Imagine there is no runtime JVM, there are no wars and jars, there is just (mostly one big) binary file executing under your Windows or Linux. The executable contains everything in it, bits of java runtime, dependencies, resources, application code.. all thanks to ahead-of-time compilation (AOT).</div><div>The key benefit is performance, such web applications should be faster and less resource intensive compared to running under JVM in the traditional way. Of course, performance of integration platforms such as midPoint is derived vastly from I/O operations, but <b>achieving GUI speedup should be realistic</b>.<div><div><br></div><div><a href="https://medium.com/swlh/graalvm-byte-code-to-bit-code-39463aa209b4" target="_blank">https://medium.com/swlh/graalvm-byte-code-to-bit-code-39463aa209b4</a><br></div><div><a href="https://www.graalvm.org/reference-manual/native-image/" target="_blank">https://www.graalvm.org/reference-manual/native-image/</a><br><div><br></div><div>This is what theory says, practically Im still unable to build midPoint as a native image to validate it. MidPoint is a complex modular spring application that makes things quite difficult.</div><div><br></div><div>I'm wondering if maybe someone from the community had the same idea as me or if anybody would like to share feedback on the topic. Everything around native building is in early stages of maturity, but it seems like a promising new trend in IT. Below I leave some technical hints, I may resume in the future if I have more time for R&D.</div><div><br></div><div>---</div><div>Im using GraalVM CE 21.3.0 java17 on linux and midPoint master (4.4). I had to bump mp's spring boot dependency to 2.5.6. These are two approaches I have tried so far:</div><div><br></div><div>1. Using the experimental spring native plugin:</div><div><a href="https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/#getting-started-native-build-tools" target="_blank">https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/#getting-started-native-build-tools</a><br></div><div><br></div><div>- This is definitely prefered way, the process should be: spring native plugin produces special AOT sources and then another maven plugin from graalvm compiles them to standalone executable.</div><div>- I had to build and use latest (0.11.0-RC1) plugin from the <a href="https://github.com/spring-projects-experimental/spring-native/" target="_blank">github</a><br></div><div>- I chose the entry point as gui/admin-gui module, so I needed to work with the pom.xml there a bit + add the spring AOT plugin.</div><div>- Unfortunately I'm stuck on various errors, mostly NoClassDefFoundError</div><div><br></div><div>2. Running graalvm native-image directly. I'm not estimating that this approach would produce usable midPoint as it skips spring AOT magic, but I wanted to try.</div><div><br></div><div>- it fails with OOM (heap) after many hours of building, even with ridiculously high Xmx:</div><div><br></div><div>root@midpoint:~/midpoint# CP=`find . -name *.jar | tr '\n' ':'`<br>root@midpoint:~/midpoint# native-image \<br>>   -Dspring.native.verbose=true \<br>>   -J-Xmx90G \<br>>   -H:Name=midPointNativeImage \<br>>   -H:+ReportExceptionStackTraces \<br>>   -Dspring.native.remove-unused-autoconfig=true \<br>>   -Dspring.native.remove-yaml-support=true \<br>>   -cp $CP \<br>>   -H:Class=com.evolveum.midpoint.web.boot.MidPointSpringApplication;<br>Fatal error:java.lang.OutOfMemoryError</div><div><br></div><div>M.</div><div><div><div><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:13px"><p><strong>Martin Lízner</strong><br><span style="font-size:11px;color:rgb(128,128,128)">chief solution architect</span></p></div><p style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:11px">gsm: [+420] 737 745 571<br>e‑mail: <a href="mailto:martin.lizner@ami.cz" target="_blank">martin.lizner@ami.cz</a></p><p style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:11px"><strong>AMI Praha a.s.</strong><br>Pernerova 697/35, 186 00 Praha 8</p><p style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:11px">tel.: [+420] 604 444 848 | web: <a href="https://www.ami.cz/" target="_blank">www.ami.cz</a></p><p style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:10px;margin-top:20px"><img src="http://www.ami.cz/images/podpis/ami-logo.png" alt="AMI Praha a.s." style="border:0px"></p><p style="font-family:Arial,sans-serif;font-size:11px;color:rgb(170,170,170)">Textem tohoto e‑mailu podepisující neslibuje uzavřít ani neuzavírá za společnost AMI Praha a.s.<br>jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně písemnou formu.<br><span style="font-size:6px"> </span><br>Tento e‑mail je určen výhradně pro potřeby jeho adresáta/ů a může obsahovat důvěrné nebo osobní<br>informace. Nejste‑li zamýšleným příjemcem, je zakázáno jakékoliv zveřejňování, zprostředkování<br>nebo jiné použití těchto informací. Pokud jste obdrželi e‑mail neoprávněně, informujte o tom prosím<br>odesílatele a vymažte neprodleně všechny kopie tohoto e‑mailu včetně všech jeho příloh. Nakládáním<br>s neoprávněně získanými informacemi se vystavujete riziku právního postihu.</p></div></div></div></div></div></div></div></div></div></div>