этот вариант мне даже больше нравится, чем меньше костылей тем лучше

@get:JsonProperty("is_pre_approved”) - это все таки костылик как по мне

Вот так например:

class ProxyMain : Main {
    private val initialized = AtomicBoolean(false)
    private val mutex = Mutex(true)
    private var main: Main by notNull()

    suspend fun set(newMain: Main) {
        if (initialized.get()) {
            mutex.withLock {
                main = newMain
            }
        } else {
            if (initialized.compareAndSet(false, true)) {
                main = newMain
                mutex.unlock()
            } else {
                mutex.withLock { 
                    main = newMain
                }
            }
        }
    }

    override suspend fun doWork(arg: String): String {
        return mutex.withLock {
            main.doWork(arg)
        }
    }
}

class ProxyMain : Main {
    private val initialized = AtomicBoolean(false)
    private val mutex = Mutex(true)
    private var main: Main by notNull()

    suspend fun set(newMain: Main) {
        if (initialized.get()) {
            mutex.withLock {
                main = newMain
            }
        } else {
            if (initialized.compareAndSet(false, true)) {
                main = newMain
                mutex.unlock()
            } else {
                mutex.withLock { 
                    main = newMain
                }
            }
        }
    }

    override suspend fun doWork(arg: String): String {
        return mutex.withLock {
            main.doWork(arg)
        }
    }
}

А зачем установка нового значения main (когда initialized.get() = true) обернута в withLock?

Ну как бы может и не нужно, но Mutex-fair, т.е. он будет сохранять порядок. Поэтому запросы на устновку и чтение будут упорядочены. А также значение main не поменяется во время исполнения doWork

Есть минус у этого подхода - все вызовы на этом классе синхронизировались 🙂

Привет. А если id - null или этого id нету в мапе, то как сортироваться должно?

Совсем красиво не вышло, но вроде работает:

val selector: (Ft) -> Int? = { it.id.let(idToPosition::get) }
val comparator: Comparator<Ft> = Comparator { ft1, ft2 -> nullsLast<Int>().compare(selector(ft1), selector(ft2)) }

UPD:  наверное чуток лучше, так хотя бы не обязательно выносить селектор:

val altComparator: Comparator<Ft> = Comparator { ft1, ft2 -> compareValuesBy(ft1, ft2, nullsLast()) { it.id.let(idToPosition::get) } }

О, всё, нашёл самое читаемое:

val altComparator: Comparator<Ft> = compareBy(nullsLast<Int>()) { it.id.let(idToPosition::get) }

объясните, зачем вся эта свистопляска с nullable, если все-равно везде полно lateinit var... чем это лучше?

Искренне не понял сравнение. Nullable применим в одних случаях, lateinit - в других.  Ну и lateinit скорее костыльное решение, которое надо использовать, если иначе никак (т.е. явно всё лучше сразу при инициализации засетать, чем потом), а nullable типы - вполне нужная вещь в любом случае (хотя конечно и с ним можно сделать странного)

я именно про костыльность lateinit... т.е. избавимся от Null pointer exception, но вот вам револьвер, стреляйте в ногу если что

К сожалению, просто не везде в существующих фреймворках работает всё делать через конструкторы. Поэтому понадобилось такое решение, поскольку интероп тоже важен.

это пичально... хотлось серебрянной пули )

Ну, пользоваться никто не заставляет, можно при желании даже себе сделать инспекцию, чтобы ругалась на ключевое слово использованное :)

Можешь не пользоваться lateinit и ручками всё проверять. Более того, ровно так и стоит делать там, где есть шанс лэйтиниту стрельнуть, то есть где порядок инициализации в объекте слишком мутный.

Он действительно хорош в тех редких случаях, когда конструктор не в твоих руках, но инициализация объекта понятна и шанс поймать NPE стремится к нулю.

someJob = lifecycleScope.launch {
        someJob?.cancelAndJoin()
        try { ... } finally { ... }
}

Это вообще законно так тормозить предыдущее задание, перед запуском нового? оно так будет работать?
Т.е. оно в принципе работает, смущает, что пока  я не сделал yield() в долгоиграющей суспенд функции, у меня новое задание стартовало раньше чем отрабатывал finally, т.е. join() фактически не работал....

А как вы знаете, что finaly{} отрабатывает раньше?

через логгер 🤔