A modern programming language that makes developers happier.

kotlinlang

:amper-intensifies: *<https://blog.jetbrains.com/amper/2025/11/amper-update-november-2025/|Amper 0.9.0 is out>!* :amper-intensifies:

This release brings a bunch of features that we’re excited about:

• An initial preview of Amper’s extensibility capabilities – you can finally try Amper plugins and let us know what you think!
• Dependency resolution graph caching
• Incremental compilation for Java
• Maven-like layout support (for easier transitions)
• Auto-sync in the IDE when using IntelliJ IDEA 2025.3 Beta
Plus plenty of new diagnostics and quality-of-life improvements!

:point_right: Check out our <https://blog.jetbrains.com/amper/2025/11/amper-update-november-2025/|blog post> and <https://github.com/JetBrains/amper/releases/tag/v0.9.0|GitHub release notes> for more info. :point_left:

Excuse my ignorance, but just for my own understanding: IIUC, in contrast to <https://declarative.gradle.org/|Declarative Gradle>, which is "just another input file format to Gradle" (besides `build.gradle` and `build.gradle.kts`), Amper is a build tool that's not based on Gradle and uses declarative syntax as a "first class citizen", correct? And out of curiosity, are there some details about what technology Amper uses? Kotlin? GraalVM?

<@U011B6K6345> Please forward those questions to <#C062WG3A7T8|>, the team is monitoring that channel and can answer there directly!

are you going to replace  gradle for android asa you replaced java for android ? gradle too slow , buggy and slow

<@U011B6K6345> sorry for the delay!

&gt; Amper is a build tool that's not based on Gradle and uses declarative syntax as a "first class citizen", correct?
Yes, you're spot on! Amper used to be just a façade on top of Gradle (and it was distributed as a Gradle plugin), but it's no longer the case. Amper is a standalone build tool with its own CLI, and its entire own implementation. We only have one specific case where this is not the case: when you build an Android application, Amper deals with dependency resolution and compilation, but the bytecode-to-dex conversion is done by the Android Gradle plugin in a generated Gradle build behind the scenes.

&gt; And out of curiosity, are there some details about what technology Amper uses? Kotlin? GraalVM?
Amper is written entirely in Kotlin, and runs on a regular JVM at the moment. We're investigating the GraalVM native image approach to improve our startup time (which is noticeable in small commands like `./amper show modules` for example), but we're not using it right now.

&gt; Amper used to be just a façade on top of Gradle (and it was distributed as a Gradle plugin), but it's no longer the case.
Ah, good to know, it seems I've missed that (quite important) transition.
&gt; We're investigating the GraalVM native image approach
That's good to hear, not only for startup performance, but also to be able to bootstrap (I assume there's a similar mechanism as the Gradle wrapper) Amper without a JVM. See <https://github.com/gradle/gradle/issues/11816> for a similar Gradle issue.
In any case, thanks for your answers, <@UBXMWAA69>!

We do have a wrapping script, but it's not yet another JVM like the Gradle wrapper. In Gradle, you have to check in the `gradlew(.bat)` script _and_ a wrapper JAR. The script starts the wrapper JAR, which in turn starts Gradle. In Amper, the `amper(.bat)` script directly launches the Amper JVM (after downloading the proper JRE and the Amper distribution).
See <https://amper.org/latest/cli/provisioning/>

Sounds good! I'll have a deeper look, and also compare to <https://github.com/eirikb/gg>.