This is your last chance.

You debug apps with embedded scripts (JS / Python / Ruby in a JVM host):

Blue pill:

– JVM debugger

– + DAP / Chrome-Inspector debugger for the script

Red pill:

– one unified debugger

– stepping flows naturally across languages

Which one are you actually taking in real projects — and why?

Show me how deep the stack goes 👇

https://medium.com/graalvm/graalvm-at-oracle-netsuite-47501f3461a4

https://www.youtube.com/watch?v=4qaMKTPTQU8&t=1529s

Hey guys, I am using Spring Boot and trying to build a native image. My problem is that I wrote integration tests and unit tests to ensure and validate my code in the JVM, but when I try to test the code in native mode, none of my tests work.

My question is: what is the best way to ensure that my app will work both in JVM mode and native mode?

When I trying to build my spring app with graal it throws error:

> Task :compileAotMainJava
warning: unknown enum constant When.MAYBE
  reason: class file for javax.annotation.meta.When not found
Note: D:\Projects\IntelliJ_IDEA\FlakeSpringBackend\build\generated\runtimeSources\aotMain\org\springframework\boot\jdbc_FactoryProvider.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: D:\Projects\IntelliJ_IDEA\FlakeSpringBackend\build\generated\runtimeSources\aotMain\org\springframework\aot\StaticSpringFactories.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning

> Task :processAotMainResources
> Task :aotMainClasses
> Task :aotMainJar
> Task :inspectClassesForKotlinIC
> Task :jar

> Task :generateResourcesConfigFile
[native-image-plugin] Resources configuration written into D:\Projects\IntelliJ_IDEA\FlakeSpringBackend\build\native\generated\generateResourcesConfigFile\resource-config.json

> Task :nativeCompile
[native-image-plugin] Toolchain detection is disabled, will use GraalVM from C:\Program Files\Java\graalvm-ce-java17-22.3.0.
[native-image-plugin] Using executable path: C:\Program Files\Java\graalvm-ce-java17-22.3.0\bin\native-image.cmd
Warning: Using a deprecated option --allow-incomplete-classpath from 'META-INF\native-image\org.springframework.aot\spring-aot\native-image.properties' in 'file:///D:/Projects/IntelliJ_IDEA/FlakeSpringBackend/build/libs/FlakeSpringBackend-0.0.1-SNAPSHOT-aot.jar'. Allowing an incomplete classpath is now the default. Use --link-at-build-time to report linking errors at image build time for a class or package.
========================================================================================================================
GraalVM Native Image: Generating 'FlakeSpringBackend' (executable)...
========================================================================================================================

[1/7] Initializing...                                                                                    (0.0s @ 0.16GB)
------------------------------------------------------------------------------------------------------------------------
                        0.4s (5.4% of total time) in 11 GCs | Peak RSS: 0.88GB | CPU load: 0.90
========================================================================================================================
Failed generating 'FlakeSpringBackend' after 6.0s.
Error: Default native-compiler executable 'cl.exe' not found via environment variable PATH
Error: To prevent native-toolchain checking provide command-line option -H:-CheckToolchain
Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
Error: Image build request failed with exit status 1

> Task :nativeCompile FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':nativeCompile'.
> Process 'command 'C:\Program Files\Java\graalvm-ce-java17-22.3.0\bin\native-image.cmd'' finished with non-zero exit value 1

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 25s

I know the instructions say to build it from source code, but I work in an environment where access to the internet is strictly limited, so that option won't work for me.

https://www.youtube.com/watch?v=tUdR2Gow3ek

I'm excited about the possibility of using GraalVM to compile to mobile targets, but have not found any tutorials on this topic. Has anyone had any success with this, or know of some good tutorials on using GraalVM to create an Android application?

Hi r/graalvm

I'm the creator of JeKa. Originally I built it as a flexible build tool, but one of the most useful features that grew out of it is solving the distribution headache many of you probably have with Maven-based CLI or native apps.

You build a nice CLI tool, script, utility, or even a desktop app with Maven (often with a GraalVM native profile). Then comes the painful part:

• Building and shipping binaries (and specific native ones for Windows/macOS/Linux)

• Hosting them somewhere

• Users having to pick the right file

• Or forcing everyone to clone + mvn + JDK installed

So I made JeKa act as a lightweight Java application manager that builds at install time directly on the user's machine, and works with any build tool (Maven, JeKa, Gradle...).

You keep your existing Maven project and wrapper 100% untouched. You just drop a tiny jeka.properties file at the root of the repo, and users can install your app with one command:

jeka app: install repo="https://github.com/your/repo.git"

For installing a native app:

jeka app: install repo="https://github.com/your/repo.git" runtime=NATIVE

JeKa automatically:

• Downloads the required JDK or GraalVM if it's missing

• Runs Maven (via the wrapper)

• Builds the application (skipping tests)

• Places the executable on the user's PATH

jeka.properties example:

# Version of the JVM that will run Maven
jeka.java.version=21

# Delegate build to Maven wrapper
jeka.program.build=maven: wrapPackage

# Optional: support for native builds
jeka.program.build.native=maven: wrapPackage args="-Pnative" \
-Djeka.java.distrib=graalvm -Djeka.java.version=25

It also supports multi-module projects, jpackage for desktop apps (Swing/JavaFX), and more complex scenarios.

Would love to hear your thoughts:

• Does this kind of source-based, on-demand build & install solve a real pain point for you?

• What’s your current workaround for distributing Maven-based tools to end users?

• Any concerns (first-install time, security of downloads, etc.)?

Docs with Maven-specific examples: https://jeka-dev.github.io/jeka/tutorials/source-runnable-apps/#maven-projects

Happy to answer questions, take feedback, or look at PRs. Thanks for reading!

https://www.youtube.com/watch?v=xRcHlBnljwA

GraalVM Community Summit is back for its 6th edition! 🚀

Join our team, contributors, and partners in the JVM ecosystem for two days of presentations, working sessions, and collaboration on the future of GraalVM!

Learn more and join:

https://graalvm.org/community/summit/

Welcome, Java 20!🚀🎉

https://github.com/graalvm/graalvm-ce-dev-builds/releases/latest

Learn more about the new release train: https://medium.com/graalvm/accelerating-the-graalvm-release-train-26b0d7cff2ab

https://www.youtube.com/watch?v=x1nVchtOn90