не ArrayList?

ArrayList это просто одна из имплементаций. Со стороны JVM нет разницы между List и MutableList, все в итоге в байткоде будет java.util.List

жаль.. спасибо за ответ

Почему жаль? Интерфейс листа в джаве всегда имеет мутабельные методы. И как я понимаю runtime эксепшн должен быть, даже после каста к MutableList, так как ImmutableList кидает UnsupportedOperationException если вызвать add/remove/etc, просто если использовать котлиновский интерфейс List, то там этих методов не будет при этом ImmutableList не позволит поменять контент листа даже если его передать в Java или явно кастонуть к MutableList

Жаль что компиляция возможна. Runtime ошибка меня не устраивает

В Java тоже runtime ошибка

Да , но в java можно сконфигурировать lint падать если используются deprecated methods как ImmutableList.add

но ведь lint не спасает от ошибок если передать immutable в метод который принимает просто java.util.List, довольно легко потерять тип (и это распространненая практика, возвращать наиболее абстрактный класс) и использовать ImmutableList как обычный List, причем случайно

Так в Java просто можно в подконтрольном коде не декларировать метод с List параметрами а декларировать как ImmutableList

В Kotlin в кодконтрольном коде можно использовать kotlin.collections.List

Ну так в Коtlin же возможна успешная конвертация его в ModifableList

Но ведь и в Java возможен его каст в List, это совершенно таже ситуация

Так в Java ето работает и так

А в Java это разве можно сделать?

Ну вот. Жаль

т.е. есть огромное число совершенно валидных ситуаций, когда тип приводится к List и все, тут никакие провверки не помогут

Да. Ето понятно. Но мне нравится guava)

У гуавы ведь та же самая проблема, они имплементят java.util.List

Да, но я в подконтрольном коде использую только колекции guava

все же мне кажется kotlin.collection.List более чистым решением, по крайней мере для своего Kotlin кода, по крайней мере методы просто не доступны, а не deprecated

Спасибо.. А известно когда релиз?

Не знаю, думаю можно спросить @ilya.gorbunov так как он автор KEEP - https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/abstract-collections.md

Про релиз могу подсказать, что пока еще не скоро, т.к. есть нерешенные проблемы в API и нет достаточно хорошей имплементации.

Ммм.. Хочу иметь гарантию что содержимое экземпляра класса ImmutableList невозможно будет удалять/добавлять/заменять никаким образом (рефлексия не в счет). То есть, например, ни после safe cast в MuttableList, ни после unsafe cast в MuttableList (как это сейчас с guava).

Возможно тогда хватит обертки над списком, сделанной с помощью

java.util.Collections.unmodifiableList

а, тогда дополнительное условие: хочу чтоб либо (1) в классе ImmutableList методьі add, delete и т.д. бьіли deprecated (как в guava) чтобьі можно бьіло сконфигурировать lint падать если он заметит использование deprecated методов, либо (2) в классе ImmutableList методьі add, delete и т.д. отсуствовали. Вариант 2 предочтительнее

Если вы уже используете ImmutableList из Guava то Collections.unmodifiableList уже точно не нужен

в классе ImmutableList методьі add, delete и т.д. бьіли deprecated

Для этого придется использовать этот класс напрямую везде в коде вместо интерфейса. И все равно есть множество случаев где тип потеряется при передаче в метод к примеру.

ImmutableList методьі add, delete и т.д. отсуствовали

Их там просто не будет на стороне Kotlin, точно так же как и сейчас, т.к. интерфейс kotlin.collection.List не имеет методов модификациию И они точно будут на стороне Java. И эту проблему не решить без своей кастомной иерархии интерфейсов коллекций

сконфигурировать lint падать если он заметит использование deprecated методов

Это уже возможно с помощью флагов Kotlin компилятора

не должно бьіть возможньім кастить к Muttable колекции

Запретить кастить вы не можете, вы и сейчас что в Java, что в Kotlin можете написать

"" as Int

, тут только падать на ворнингах поможет и то не всегда. И вообще запретить кастить даже без ворнинга не получится, просто по причине того, что Mutable интерфейс наверняка будет наследников Immutable интерфейса (как это сейчас и работает в Kotlin) иначе очень его не удобно использовать. И kotlinx.collections.immutable эту проблему вам не решат, так же как она не решается через Guava что на стороне Kotlin, что на стороне Java. Но если честно я не вижу большой проблемы совсем, если кто-то пишет код который кастит без проверки типа и затем пытается поменять внутреннее состояние объекта то это его проблема, такой код плох сам по себе. kotlin.collections.List решает большинство случаев со случайной модификацией, но если хочется серьезной защиты от модификации, то просто можно обернуть в Collections.unmodifiableList или использовать Guava ImmutableList как основу для коллекции и в дальнейшем использовать интерфейс kotlin.collections.List

Для этого придется использовать этот класс напрямую везде в коде вместо интерфейса.

Да, я так и делаю. Для этого это и нужно.

Нет, это не так

да но в java я не могу кастить

List o1 = (ArrayList) ImmutableList.of();

- не позволит компилятор

Ну так вы и в Котлине не можете это сделать

с guava ImmutableList могу

Зато в Java можете

List o1 = ImmutableList.of();

Я имел ввиду что в Kotlin я могу c guava ImmutableList сделать так

val mutableIList = ImmutableList.of(1,2) as MutableList<Int>

Вы можете скастить, но это не даст клиенты модифицировать лист

Mutable интерфейс наверняка будет наследников Immutable интерфейса (как это сейчас и работает в Kotlin) иначе очень его не удобно использовать.

жаль(

Вы только что написали 100% аналог Java кода: mutableIList = (List) ImmutableList.of(1,2)

Да, но мьі же хотим сделать Kotlin лучше java

Просто вы пишете, что Java каким то образом защищает вас от такого поведения, я же говорю что нет, поведение идентичное

В Java просто уже существует много всяких статических анализаторов которьіе можно настроить падать при компиляции

Какой статический анализатор будет ругаться на это?

mutableIList = (List) ImmutableList.of(1,2)

или на это:

void mutateList(List list) { … }

mutateList(ImmutableList.of(1,2))

error-prone (хотя не уверен)

Я совсем не уверен, так как абсолютно валидный кейс

Хорошо, возможно в Java и нет таких анализаторв..

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

Но будущая возможость в Kotlin кастить в Immutable в Mutable это как-то странно наверное..

но лечение (полностью несовместимые интерфейсы мутабильных и иммутабельных коллекций, не совместимые с java.util.List) хуже болезни (программист может явно прикастить к мутабельному типы, вызвать метод add/remove и получить UnsupportedOperationException)

это да..

Это не возможность Kotlin, это то, как работают интерфейсы на JVM и много где еще

хорошо, понятно

Он и будет предупреждать на стороне Котлин о том что “This cast can never succeed” и падать с ClassCastException

Эх..

и кстати тут вы правы, ImmutableList из kotlinx.immutable.collections спасет от проблемы с кастом, но опять же, только на стороне Kotlin: https://try.kotlinlang.org/#/UserProjects/esb1haphvlhi3d0jasdbj5adh9/n6lb53kucglob8ofpnu4s7rie7