А при подключении второго монитора, винда нынче научилась запоминать состояние окон и если вы постоянно прикручиваете второй экран к своему ноуту, то она этот экран запомнит и будет восстанавливать окна, которые были на нём открыты при подключении
Я эту фичу ждал со времен семёрки, серьёзно. Реально полезно будет.
если в дальнейшем кто-то захочет расширить функционал Java-метода, добавив обработку null-значения, и уберёт аннотацию @NotNull (не проставив @Nullable) — то это никак не отразится на компиляции Kotlin-кода, и в нём опять возникнет риск получить NPE в рантайме
О да, у нас был как раз такой случай. У нас старый код написал на Джаве, а новый на Котлине. И один из разработчиков решил добавить в метод джавакода возможность обрабатывать null, и просто убрал NotNull, а Nullable не проставил... Итог был предсказуем :(
В теории должно ловиться, а на практике ревьювер не заметил.
А при подключении второго монитора, винда нынче научилась запоминать состояние окон и если вы постоянно прикручиваете второй экран к своему ноуту, то она этот экран запомнит и будет восстанавливать окна, которые были на нём открыты при подключении
Я эту фичу ждал со времен семёрки, серьёзно. Реально полезно будет.
Полностью согласен, другие продавцы тоже имеют право поступать абсолютно так же.
если в дальнейшем кто-то захочет расширить функционал Java-метода, добавив обработку null-значения, и уберёт аннотацию
@NotNull(не проставив@Nullable) — то это никак не отразится на компиляции Kotlin-кода, и в нём опять возникнет риск получить NPE в рантаймеО да, у нас был как раз такой случай. У нас старый код написал на Джаве, а новый на Котлине. И один из разработчиков решил добавить в метод джавакода возможность обрабатывать null, и просто убрал NotNull, а Nullable не проставил... Итог был предсказуем :(
Другие описанные случаи я не встречал.