Спасибо большое за оценку. Очень рад, что статья понравилась.
Использование класса Class используется очень часто в различных библиотеках, там где нельзя заранее знать все случаи использования. В groove зачастую используется, в Spring Framework сплошь и рядом, в сериализаторах, наподобие Jackson. Уверен, если вы поищите в своем проекте через Intellij IDEA по области Scope - Class<,то найдёте не одно место использования.
Я вроде написал, что это похоже на баг. Если попробовать использовать cast, то скомпилировать код не получится, а вот автовывод типа работает. Это потому, что в документации это разные разделы. Автовывод появился только в 9 версии Java и видимо не учли этот момент в проработке компилятора. Мне кажется, даже сделать багфикс этого момента будет не сложно.
Да, идея в том, что вот для такой сигнатуры метода
<T> T get();
тип <T>, определяет не метода, а вызывающий код. И такая сигнатура
<T extends Runnable> T get();
будет тоже определяться вызывающим кодом, но в самом методе будет создаваться реализация, которая точно будет расширять Runnable и будет совместима с типом Т.
Да, это выглядит очень странно, получается есть нелогичная конструкция в языке. Ведь мы не можем узнать какой тип хочет получить вызывающий код. Единственная возможность это использовать такую сигнатуру
<T> T get(Class<T> type);
А такой конструкции, вызывающий код должен нам сообщить, какой тип он хочет вернуть. Ну а если не сообщает, передавая null, это уже выстрел в ногу :) Именно поэтому, что такая сигнатура имеет хоть какой-то смысл, используется в библиотеках и является рекомендуемой в блоке "Указание типа в параметрах".
В Kotlin используется ключевое слово refied для типа, но это просто синтаксический сахар, который под капотом использует как раз Class<T>.
Не обязательно только генерация. Конкретная реализация может быть скомпилирована и подтягиваться из другой библиотеки, но верно, что реализация известна только в рантайме и компилятор не может это поверить никак, если это не финальный класс.
он проверит, если класс финальный или у нас пересечение двух классов, так как множественное наследование классов запрещено. А если нет, то разницы с интерфейсом нет. Я пытался это объяснить в блоке «Переход на классы вместо интерфейсов».
Проблема в полиморфизме :) все хорошо работает, если вывод будет на классах, компилятор проверит, а вот интерфейсы не проверяются. Так как реализация не известна, реализация может быть в рантайм через прокси.
Неплохой вариант. И так как нужно проверять именно сигнатуру, кажется, такое правило не сложно будет создать. Спасибо за подсказку, нужно будет посмотреть в эту сторону.
Я согласен с вами.
Хочу немного уточнить, я не жалуюсь на СБ, мне просто кажутся не очень эффективны способы их работы. И я просто решил поделиться своим мнением и посмотреть, согласен ли кто-нибудь с такой точкой зрения.
Спасибо за то, что поделились вашей точкой зрения
Спасибо за хороший комментарий.
Хотелось бы узнать ваше мнение, а нужно ли сотруднику СБ/ЭБ быть вовлеченным в процесс? Или такое вовлечение излишне и затраты, которые нужны для того, чтобы провести такую реструктуризацию принципиально не изменят уровень безопасности?
Несомненно появится. Хотя получается я так и не донёс мысль. Смысл не в том, чтобы разрешить, а в том, что нужен другой подход к запрещению/разрешению. Идущий от потребностей. В компании, в которой я работаю, есть такое приложение «Безопасный интернет». По сути это браузер открывающийся на удаленной виртуалке. Если что-то и будет заражено, то не на рабочей машине. Да он не идеален, не покрывает всех потребностей, зачастую просто не удобен, но сам ход мысли, по мне, – очень хороший. Вот я считаю, нужно двигаться в эту сторону.
Спасибо большое за оценку. Очень рад, что статья понравилась.
Использование класса Class используется очень часто в различных библиотеках, там где нельзя заранее знать все случаи использования. В groove зачастую используется, в Spring Framework сплошь и рядом, в сериализаторах, наподобие Jackson. Уверен, если вы поищите в своем проекте через Intellij IDEA по области Scope -
Class<,то найдёте не одно место использования.Я вроде написал, что это похоже на баг. Если попробовать использовать cast, то скомпилировать код не получится, а вот автовывод типа работает. Это потому, что в документации это разные разделы. Автовывод появился только в 9 версии Java и видимо не учли этот момент в проработке компилятора. Мне кажется, даже сделать багфикс этого момента будет не сложно.
Да, идея в том, что вот для такой сигнатуры метода
тип <T>, определяет не метода, а вызывающий код.
И такая сигнатура
будет тоже определяться вызывающим кодом, но в самом методе будет создаваться реализация, которая точно будет расширять Runnable и будет совместима с типом Т.
Да, это выглядит очень странно, получается есть нелогичная конструкция в языке. Ведь мы не можем узнать какой тип хочет получить вызывающий код. Единственная возможность это использовать такую сигнатуру
А такой конструкции, вызывающий код должен нам сообщить, какой тип он хочет вернуть. Ну а если не сообщает, передавая null, это уже выстрел в ногу :) Именно поэтому, что такая сигнатура имеет хоть какой-то смысл, используется в библиотеках и является рекомендуемой в блоке "Указание типа в параметрах".
В Kotlin используется ключевое слово refied для типа, но это просто синтаксический сахар, который под капотом использует как раз Class<T>.
Не обязательно только генерация. Конкретная реализация может быть скомпилирована и подтягиваться из другой библиотеки, но верно, что реализация известна только в рантайме и компилятор не может это поверить никак, если это не финальный класс.
он проверит, если класс финальный или у нас пересечение двух классов, так как множественное наследование классов запрещено. А если нет, то разницы с интерфейсом нет. Я пытался это объяснить в блоке «Переход на классы вместо интерфейсов».
Проблема в полиморфизме :) все хорошо работает, если вывод будет на классах, компилятор проверит, а вот интерфейсы не проверяются. Так как реализация не известна, реализация может быть в рантайм через прокси.
Неплохой вариант. И так как нужно проверять именно сигнатуру, кажется, такое правило не сложно будет создать. Спасибо за подсказку, нужно будет посмотреть в эту сторону.
Я видео не снимал, но запись велась силами JB. Ссылки на видео пока не присылали. Если пришлют, то выложу.
Хочу немного уточнить, я не жалуюсь на СБ, мне просто кажутся не очень эффективны способы их работы. И я просто решил поделиться своим мнением и посмотреть, согласен ли кто-нибудь с такой точкой зрения.
Спасибо за то, что поделились вашей точкой зрения
Хотелось бы узнать ваше мнение, а нужно ли сотруднику СБ/ЭБ быть вовлеченным в процесс? Или такое вовлечение излишне и затраты, которые нужны для того, чтобы провести такую реструктуризацию принципиально не изменят уровень безопасности?
Спасибо за комментарий.
Да, согласен.
Исследования не проводил, мне такую информацию не представляли и получить её не получится, но с теми с кем общался были как раз оттуда
Да согласен, тут можно обидится. Но не это цель статьи
Я как-то не одной жалобы не написал
Да тема пересекается, но статьи о разном