Так это уже совсем другой вопрос, который как раз обсуждали выше

Отсутствие this - это вообще не проблема

Это очень редко нужно, ну и одна лишняя аллокация на всю жизнь приложения - это не так дорого

ну это можно сделать один раз

Коллеги по спрингу, подскажите плз. Создал МР в спринг-дата-коммон на ограничение типа на экстеншне к
CrudRepository, думал там косяк. https://github.com/spring-projects/spring-data-commons/pull/424

Косяк в том что экстеншн вида <T, ID> CrudRepository<T, ID>.findByIdOrNull(id: ID) принимал туда nullable тип, и если туда попадал null соответственно падал в джавке на <ID> findById(id: ID) { checkNotNull(id) }

Оказалось что косяк проявляется  только если наследоваться не напрямую от CrudRepository, а только через PagingAndSortingRepository(JpaRepository), там почему-то по пути теряется понимание что он хочет TypeVariable(ID), и позволяет отдать туда просто ID!

Ревьювер говорит - мол косяк в котлине, проверьте есть ли такая бага в их трекере.
Кто-нибудь в курсе почему так может быть?

Я не уверен, но кажется что там пляски с наследованием класс_в_котлине -> класс_в_джаве -> класс_в_котлине, и в процессе потерялись типы.

там котлин класс только конечный, когда создается котлиноинтерфейс наследующий джаву

из спринга котлиновый только экстеншн

А ну так где же тогда ошибка?

секунду.

вот 3 джава интерфейса

А, и при использовании .ext-функции на наследнике у неё стираются типы?

если отнаследовать котлиноинтерфейс из второго, то будет ошибка

Если из нижнего - не будет

Имхо, фикс уместный, а у разработчиков котла наверняка есть ответ почему ext-функции для жавовых наследников теряют null-safety.

(честно признать я удивлён, что нигде в java коде не увидел аннотации @NonNull)

там на уровне пакета

Что местами добавляет веселья с equals)

падает то вот тут

У кого можно узнать как задумано? В трекере спросить? Хотелось бы как-то обосновать фикс, раз он внезапно встретил сопротивление.