Hi, is JBR a pre-req for Amper to execute builds? ...

# kotlin-toolchain

[suresh]

Hi, is JBR a pre-req for Amper to execute builds? While the AMPER_JAVA_HOME env variable allows for an override, Amper currently defaults to downloading JBR 21. Would it be possible for Amper to leverage an existing, compatible JDK by default?

[joffrey]

We must distinguish the runtime of Amper itself from the JDK that Amper uses to build your code. The JBR is only a runtime for Amper. We could even use a jlink-ed minimal JRE for this, or a GraalVM native image with no JRE at all. It should be irrelevant to the user so there is no real reason to override this.

By default, the user's code is built using the Amazon Corretto JDK 21, which is also automatically downloaded. We plan to enable customizing this of course.
There is also an issue about respecting `JAVA_HOME`: https://youtrack.jetbrains.com/issue/AMPER-808/Unnecessarily-download-Sorretto-JDK-even-though-JAVAHOME-is-already-set-to-a-local-JDK. But this is more debatable.

[suresh]

user so there is no real reason to override this.

In enterprise and CI/CD environments, it’s often better to use the existing JDK, and sometimes we’re restricted to downloading resources only from Maven Central.

[joffrey]

I understand this, but again we're not talking about the JDK toolchain, but the Amper runtime

[suresh]

we’re not talking about the JDK toolchain, but the Amper runtime

Thanks, that’s clear. We still need to download the bootstrapping JDK (as per the current amper/amper.bat scripts), and we might run into access issues. It’d be good to have a fallback option, like using an existing, compatible JDK as the Amper runtime. Gradle does that. (I am not saying we should following the gradle route 🙂 )

[joffrey]

But what if Amper becomes a native GraalVM image and doesn't run on a JRE?

[joffrey]

I understand the problem with downloads and access in general, but then I guess we should rather look at the Amper distribution itself (which by the way could contain its runtime)

[suresh]

native GraalVM image|

Are there any plans to create native image? It will be interesting to see how the new plugins will play out in the native image world.

Amper distribution itself

Make sense.

[joffrey]

Are there any plans to create native image? It will be interesting to see how the new plugins will play out in the native image world.

No very short terms plans, but we're open to the idea. With project Crema it should be possible to deal with plugins

[suresh]

@joffrey What is the eventual plan for Amper distribution? Will it be distributed through Central (like Maven wrappers)?

[suresh]

With project Crema

@joffrey https://github.com/borkdude/cream - Crema compiled clojure runtime. Might be intesresting to you

[joffrey]

Hi Suresh! Thanks for the link! And by the way, sorry for the silence on the last message. I had prepared a reply a long time ago and never hit send 🤦‍♂️

What is the eventual plan for Amper distribution? Will it be distributed through Central (like Maven wrappers)?

I don't think it will. The Amper distribution is downloaded by the Amper wrapper scripts, so it could be hosted anywhere (like any other toolchain downloaded by Amper). And the wrapper scripts are never downloaded via any Maven dependency resolution mechanism, it's the first thing you need to download to be able to use Amper. So there is no real point to publish these things to Maven Central, they just happened to be put in a maven-like repo because it was a quick and easy storage & versioning solution at the time.

Eventually, we'll most likely move towards a native image distribution, and that will not need to be hosted on Maven Central either. Maybe <http://downloads.jetbrains.com|downloads.jetbrains.com>.