JetBrainsRuntime VS Spring Loaded

JetBrains have their tweaks to the JRE available: https://github.com/JetBrains/JetBrainsRuntime

The major problems begin when you want to leverage the GPU or multimedia components in which case you would want something else.

Jetbrains Runtime – this is bundled with IntelliJ and Android Studio, but with patches focused on optimization for use within an Interactive Development Environment context – doing incremental builds, hot reload of class definition, and embedded Chromium in the runtime. I do not believe the added features are useful for building and archiving Android Applications for distribution, but it will work non-the-less.

https://github.com/JetBrains/JetBrainsRuntime

Also with 'Java on Truffle' on GraalVM you can use enhanced class reloading

However, I am running IntelliJ on Asahi since June already. They did not provide offical Linux arm64 support, but what since May, when they released the first 2022.2 EAP, they switched to JBR 17 (the JetBrains Java Runtime). JBR 17. Fortunatly, in May, they started to release JBR builds for Linux am64, starting with JBR 17.0.3-b463.3. That meant we had everything we needed to run IntelliJ on Asahi: I just had to set the env var IDEA_JDK=/path/to/arm64/jbr/ to make IntelliJ use the correct JBR. Besides that it was necessary to download a fsnotifier version that was build for arm64 and set the path in ~/.config/JetBrains/IntelliJIdea2022.3/idea.properties.

Have you tried the JetBrains Runtime with DCEVM? https://github.com/JetBrains/JetBrainsRuntime/releases/tag/jbr17.0.2b396.4

This project's key is replacing x86_64 Jetbrains Runtime (https://github.com/JetBrains/JetBrainsRuntime) to arm64 Jetbrains Runtime. Arctic Fox IntelliJ Core version is 2020.3.1, maybe google upgrade core version to 2021.1 as soon as possible. (IntelliJ Core version 2021.1 released at a few days ago.)

https://github.com/JetBrains/JetBrainsRuntime

Hot reloading with spring-loaded doesn't support anything beyond JDK 8. New spring-devtools is much slower.

When using Java, with say, jib and skaffold, when a change is detected the image is rebuilt with some fairly smart cacheing being done to minimize the build time.

In more interesting setups, the class files aren't in the image but rather mapped in - much the same way one would with dynamic and then a hot reload - https://docs.spring.io/spring-boot/docs/1.3.8.RELEASE/refere...

> Spring Loaded goes a little further in that it can reload class definitions with changes in the method signatures. With some customization it can force an ApplicationContext to refresh itself (but there is no general mechanism to ensure that would be safe for a running application anyway, so it would only ever be a development time trick probably).

And this way, the container can remain the same with the class files being changed underneath it.

https://github.com/spring-projects/spring-loaded