when are kotlin objects intantiated? in `object MyObj { val blah=getBlah }`, when is getBlah called?...

# announcements

[christophsturm]

when are kotlin objects intantiated? in object MyObj { val blah=getBlah }, when is getBlah called? when the containing file is imported? or when a method references MyObj.blah?

[Marc Knaup]

Depends on the platform.
On JVM the first time you use MyObj.
On JS upon script loading.
I don’t know on Native.

[Rob Elliot]

Call order being platform dependent could introduce some really nasty to diagnose bugs.

[Marc Knaup]

Yeah, it's a known issue.

[Rob Elliot]

@christophsturm in the spirit of “teach a man to fish” - it would be pretty easy to check by experimentation:

fun getBlah(): String {
  println("getBlah called")
  return "blah"
}

object MyObj { val blah = getBlah() }

fun main() {
  println("start")
  val myObj = MyObj
  println("MyObj referenced")
  val blah = myObj.blah
  println("MyObj.blah referenced; was $blah")
}

[Rob Elliot]

Prints:

start
getBlah called
MyObj referenced
MyObj.blah referenced; was blah

on the JVM, which shows it isn’t loaded immediately, but is loaded when MyObj is first referenced rather than when MyObj.blah is referenced.

[Marc Knaup]

Yup, JVM implementation is the most correct one (though not perfect).

[christophsturm]

is there a way to instantiate all the objects in a package without classpath scanning?

[Marc Knaup]

not really 🤔

[christophsturm]

i guess there isnt because of the way classloaders work.

[christophsturm]

probably the fastest way is to find the classes directory and load all files in the directory that corresponds to that package.

[Marc Knaup]

Can’t you just manually load them in code?

fun preload() {
   Obj1
   Obj2
   Obj3
   // …
}

[Rob Elliot]

If your app is dependent on something loading at a certain point in the lifecycle I’d suggest doing it explicitly rather than depending on an object being referenced.

[christophsturm]

ok my usecase is this: I’m writing a small fast test runner from scratch:

```package nanotest

import strikt.api.expectThat
import strikt.api.expectThrows
import strikt.assertions.all
import strikt.assertions.containsExactlyInAnyOrder
import strikt.assertions.hasSize
import strikt.assertions.isA
import strikt.assertions.isEqualTo
import strikt.assertions.isFalse
import strikt.assertions.isLessThan
import strikt.assertions.isTrue
import strikt.assertions.map
import java.lang.management.ManagementFactory
import java.util.concurrent.CompletableFuture
import java.util.concurrent.TimeUnit

fun main() {
    val testFinished = CompletableFuture<Unit>()
    val failingTestFinished = CompletableFuture<Throwable>()
    val results = Suite {
        test("firstTest") {
            expectThat(true).isTrue()
            testFinished.complete(Unit)
        }
        test("failing test") {
            try {
                expectThat(true).isFalse()
            } catch (e: AssertionError) {
                failingTestFinished.complete(e)
                throw e
            }
        }
        context("child context") {
            context("grandchild context") {
                test("failing test") {
                    expectThat(true).isFalse()
                }
            }
        }
    }.run()
    expectThat(results) {
        get(SuiteResult::allOk).isFalse()
        get(SuiteResult::failedTests).hasSize(2).all {
            get(TestFailure::name).isEqualTo("failing test")
            get(TestFailure::throwable).isA<AssertionError>()
        }
        get(SuiteResult::contexts).map { it.name }
            .containsExactlyInAnyOrder("root", "child context", "grandchild context")
    }
    expectThrows<RuntimeException> { results.check() }
    testFinished.get(1, TimeUnit.SECONDS)

    Suite(listOf(TestContextTest.context, SuiteTest.context, ContextTest.context)).run().check()
    val uptime = ManagementFactory.getRuntimeMXBean().uptime
    println("finished after: ${uptime}ms")
    expectThat(uptime).isLessThan(1000) // lets see how far we can get with one second
}

and right now i have a list of test classes in my bootstrap test. (i run the bootstrap test in main and after checking that it runs all the tests and fails on failure i run the rest via the normal test runner)
right now i have a list of all the test objects there and i wonder if i can automate it while staying in my 1000ms budget

[Marc Knaup]

I have no idea how that’s related 🙂

[christophsturm]

currently i specify all the classes that contain test contexts: Suite(listOf(TestContextTest.context, SuiteTest.context, ContextTest.context)).run().check()

[christophsturm]

and trying to avoid that was the motivation for the question. but i guess there is no simple trick thats faster than just walking the classes directory

[Rob Elliot]

Classpath scanning is what nearly all test frameworks do, but personally I prefer your current solution - explicit registering of the tests in code. I hate reflection; slow and prone to surprise you (delete that .kt class and the test still runs because the .class file is still there)

[Rob Elliot]

In combination with a linting rule that requires all code to be reachable from a main method

[Marc Knaup]

I don’t know what test contexts are about. But it sounds weird that you need to have all of them upfront.
Can’t you register them lazily as each test class is used?

[christophsturm]

thats just how i tell the test runner that i want it to run those tests.

[christophsturm]

@Rob Elliot I have seen that problem with tests that still run after the kt file is removed too. but thats also a bug in the build system then. it should remove classes where the source was removed.

[Marc Knaup]

Ah okay. In that case you’ll need either that or a compiler plugin (e.g. ksp).

[christophsturm]

@Rob Elliot what linter would i use for such a rule?

[Rob Elliot]

Sorry, that was a misleading comment - it was a general “how I would like to approach the problem” rather than “this is how I actually do it”. I haven’t yet looked hard to see if any linters can do that.

[christophsturm]

ah ok. its an interesting idea. I was just asking because i have not tried kotlin linters myself

[Animesh Sahu]

On K/N as well, its set up at the first access.