is withEnvironment completely broken on newer JDKs...

# kotest

[snowe]

is withEnvironment completely broken on newer JDKs? I’ve added jvmArgs("--add-opens=java.base/java.util=ALL-UNNAMED"), but am still getting the

Unable to make field final java.util.Map java.util.Collections$UnmodifiableMap.m accessible: module java.base does not "opens java.util" to unnamed module @4d5d943d

error.

test is pretty simple:

class CompanyIdProviderTest : FreeSpec({
    "different environments result in different company ids" {
        withEnvironment("ENVIRONMENT", "prod") {
            System.getenv("ENVIRONMENT") shouldBe "BarValue" // System environment overridden!
        }
    }
})

not sure if it’s something with multimodule gradle projects or what…

tasks.withType<Test>().configureEach {
    systemProperty("java.util.logging.manager", "org.jboss.logmanager.LogManager")
    jvmArgs("--add-opens=java.base/java.util=ALL-UNNAMED")
}

tasks.getByName<Test>("test"){
    jvmArgs("--add-opens=java.base/java.util=ALL-UNNAMED")
    useJUnitPlatform() {
        excludeTags("integration", "recording-api")
    }
}

[LeoColman]

There is a workaround, I think it's on Kotest docs somewhere

[LeoColman]

Can't find it atm

[snowe]

yeah I haven’t managed to find anything in my searches… the ALL-UNNAMED is the only thing I can find…

[snowe]

oh strange. it works in the command line, but not intellij. Hm.

[snowe]

what. now it works in intellij after running it in the command line. wtf.

[snowe]

and now it’s back to broken….

[Emil Kantis]

Are you running individual tests? They are run using the intellij runner, and gradle config does not apply

[snowe]

oh… I did not know that…

[snowe]

yes, that’s exactly what I was doing.

[Emil Kantis]

https://github.com/kotest/kotest-intellij-plugin/issues/178 could be useful for you if fixed perhaps..

[snowe]

ah, I thought it was an intellij issue. so it’s a gradle issue?

[Emil Kantis]

It's a mix of things.. The way Kotest works with nested tests/containers is not really compatible with how Gradle works. If you try to run an isolated nested test, we can't really get gradle to do that with current filtering/discovery mechanisms

[Emil Kantis]

So I think that's why we fall back to always using the IntelliJ runner for isolated tests

[Emil Kantis]

I'm not 100% sure how it works tbh.. I would like to look into it and try to fix it at some point but it's usually really poorly documented and hard to figure out.. plus I have limited time 😞

[snowe]

I see. ok, so is it possible to get intellij to just run the individual test with the addopens flag?

[Emil Kantis]

Think you could..

[Emil Kantis]

pardon my piss poor writing on the touch pad.

[snowe]

I did not realize you could modify underlying configs like that. that’s incredibly useful for a ton of other situations. thank you

[Emil Kantis]

youre welcome! 🙂

[snowe]

worked. I’m gonna go use that for all the aws toolkit stuff now lol.

[snowe]

image.png

[CLOVIS]

The correct syntax in Gradle configuration is

jvmArgs("--add-opens", "java.base/java.util=ALL-UNNAMED")

It mirrors the CLI syntax, in which both are separated by a space (exactly like they would be split in argv)

I recommend setting it in the Gradle build and avoiding changing the IntelliJ run configuration as much as possible, because the run configuration doesn't impact your CI, while your Gradle config does 🙂

[Emil Kantis]

You need to set it in both, check the thread history for context