Comments 13
Спасибо! Отличная статья и написана приятным слогом!
Это несколько ограниченно, так как для создания типа-суммы вы должны контролировать всех наследников: в тип-сумму, например, нельзя включить класс стандартной библиотеки.
Нет никакого ограничения, в тип-сумму "включаются" не типы, а конструкторы. Которым соответствуют отдельные конкретные классы, созданные специально для этой цели.
Возможно, вы путаете тип-сумму и тип-объединение.
Спасибо.
Не подскажете, когда там планируют от Type Erasure избавиться и завести поддержку обобщений на уровне байт-кода?
Никогда не планируют. С type erasure вполне можно жить. Специализация будет разве что для параметризации примитивами, когда её завезут.
можно сделать не ломая обратную совместимость.
Предложите, как.
Не ломая обратную совместимость никак не сделаете. Вот простой вопрос на подумать для затравки. Есть класс AbstractList и есть класс ArrayList, его наследник. В Java-программах есть типы AbstractList<?>, ArrayList<?>, AbstractList<String>, ArrayList<String>. Если специализировать, то в рантайме это должно быть четыре отдельных класса. Нарисуйте их иерархию.
Ждем вторую часть
Есть же уже.
За ссылку на продолжение спасибо, пропустил! Может ее в начало статьи вставить?
Разве специализацию не планируют использовать ещё для "компактных" массивов из value-based types? Там, где предлагается например object header в массив класть не по количеству элементов, а только один раз в самом начале. Или они будут считаться как параметризация примитивами? Или саму идею решили из планов выбросить?
Я доклады про такое периодически видел примерно с момента выхода Java 8 (более формально — с момента, как я узнал про Project Valhalla и стал читать чего же там делается).
С каждым новым релизом писать ООП-код в Java становится всё труднее. Я думал, что после приватных методов в интерфейсах меня ничем не удивишь. Но нет, теперь у нас есть Sealed-классы. То есть, родительский класс может зависеть от своих потомков. Браво, Java!))
Java 17 для тех, кто не следил. Часть 1