mkay, I'm a bit lost here. newest IntelliJ, JVM 21...

# amper

[Jakub Gwóźdź]

mkay, I'm a bit lost here. newest IntelliJ, JVM 21/Temurin, MacOS:
1. create new project, kotlin/amper/jvm console (product: jvm/app), let's name it "autocloseable" or whatever
2. check amper wrappers that it is 0.7.0
3. replace content of main.kt with

import java.net.http.HttpClient

fun main() {
    val client: HttpClient = HttpClient.newHttpClient()
    client.close()
}

Nothing suspicious here, usual code, right?
4. Run main.kt (from IntelliJ, or via ./amper run

00:01.810 INFO  :autocloseable:compileJvm Compiling module 'autocloseable' for platform 'jvm'...
00:02.974 ERROR :autocloseable:compileJvm e: file:///Users/jakub.g/personal/jakub-gwozdz/autocloseable/src/main.kt:5:12 Unresolved reference 'close'.

ERROR: Task ':autocloseable:compileJvm' failed: Kotlin compilation failed:

e: file:///Users/jakub.g/personal/jakub-gwozdz/autocloseable/src/main.kt:5:12 Unresolved reference 'close'.
16:08:04: Execution finished 'run -m autocloseable --main-class MainKt'.

How. How is it possible that <http://java.net|java.net>.http.HttpClient, which obviously is AutoCloseable , yields this error for me?

Someone please confirm or deny this 🙂

[utikeev]

Hello! I think it has to do with the HttpClient becoming AutoCloseable only since Java 21 while Amper uses Java 17 as the default JVM release version .

settings:
  jvm:
    release: 21

should do the trick 🙂

We'll discuss the default here a bit more, thanks for bringing it up!

[Jakub Gwóźdź]

Ooooo indeed. Thanks for the explanation, I wasn’t aware

[Jakub Gwóźdź]

I think it would be enough if IntelliJ project had the same jvm as amper, then users would figure out the problem

[utikeev]

Yeah, we should definitely propagate the set JVM release level into the module language level (we do that for Kotlin, but not for Java).
However, there is an issue with HttpClient.close not being reported as incorrect API usage even in projects under other build systems. I have filed an issue about that:
IDEA-375650

[utikeev]

As for Amper not propagating the correct Java language level, I've also filed an issue: AMPER-4479

[suresh]

@utikeev Hi, how can we use the latest Kotlin version (2.2.0) with Amper, similar to how we’d handle a JVM release? Also, can we expect version 0.8, which includes custom tasks, any time soon?

[utikeev]

Hi! Currently, we lack the ability to provide a custom version of toolchains (both Kotlin compiler and JDK). Here's an issue that you can upvote and watch—AMPER-424.
At the moment we have an approach of providing some sensible defaults which are the latest Kotlin compiler and the latest LTS JDK but that's definitely something we'd want to change in the foreseeable future. So Kotlin 2.2.0 will arrive with the next Amper release.

As of 0.8, we still got plenty of stuff to do for the extensibility so we expect it to arrive not earlier than in autumn (please, treat it as a rough approximation). However, we'll discuss the possibility of releasing a minor version of 0.7 with the Kotlin compiler updated to 2.2.0.

NB: JVM release level and Kotlin language level are not affecting the choice of toolchain—they only set what language features and parts of standard libraries are available. Also, currently bundled Kotlin 2.1.20 supports language level of 2.2, so you might try some of the experimental features from it as well by setting kotlin.languageVersion to 2.2, but they aren't guaranteed to work the same way as they do in Kotlin 2.2.0.