Если завтра будет вызывать, завтра и поменяете. Давайте сразу добавим методу тридцать дополнительных параметров, ведь они завтра могут пригодиться. Получатель невиртуального метода — это просто один из его параметров.
Правильно вызывать через экземпляр бина.
Ну если вы придумали себе надуманные правила, то тогда да, правильно.
Кажется, в этом нет смысла. Эта строчка совершенно очевидно выполняется только при cur == -1. Или сообщить, что "если бы это условие было не под if (cur == -1), оно не было бы всегда истинно"?
Это натянуто. Ты в каждом методе, принимающем коллекцию, ожидаешь увидеть в ней null? Я вот нет. Иногда метод вправе ожидать каких-то гарантий относительно аргументов. Особенно приватный метод.
Мне это не нравится. Придётся компилировать всё равно с разными таргетами, но сливать класс-файлы в одно место. Можно запутаться или сломать какие-нибудь тулзы.
Почему хуже? XML внутри XML смотрится более органично, чем груви внутри XML. И это лучше, чем Gradle.kts, потому что менее кардинально и требует меньших усилий.
Я не проверял, но говорят, что если это делать как многомодульный мавен-проект, то IDE взлетит из коробки. А здесь надо специально распознавать нестандартный плагин, который хотя и неплох, но — посмотрим правде в глаза — имеет всего 16 звёзд на гитхабе.
Не поясните? Это же фишка Java 9, как ее к андроиду-то прикручивать?
Любая джава (и даже недоджава Андроида, я надеюсь), которая не в курсе этой фичи, будет просто игнорировать лишнюю строчку в манифесте и лишние файлы внутри META-INF. Если их не учитывать, всё остальное — вполне корректная Java-8-библиотека.
Любую проблему можно решить например при помощи gmaven — написав код на груви
На вкус и цвет все фломастеры разные. Я уж скорее перейду на Gradle+Kotlin script, чем куски груви буду втыкать.
Не туда копаешь. Неявный final внутри метода появился в multi-catch в седьмой джаве. Правда про это мало кто знает кроме разработчиков IDE.
Если же рассматривать объявление класса, то поля, объявленные в интерфейсе, неявно final (и static) с первой джавы. Ну и константы enum туда же.
В принципе доклад на технической конференции и должен быть похож на стендап. Чего в этом плохого?
Масса фотона нулевая, но солнце фотоны притягивает.
В задаче со стримами использование raw-type и объектного стрима для примитивного типа никого не напрягло?
Кстати, более интересный вопрос, как исправить код, чтобы получить желаемый результат, при условии, что сигнатура метода фиксирована.
На StackOverflow минус платный, стоит единичку рейтинга (хотя там рейтинг совсем по-другому считается). Думаю, это на пользу.
Если завтра будет вызывать, завтра и поменяете. Давайте сразу добавим методу тридцать дополнительных параметров, ведь они завтра могут пригодиться. Получатель невиртуального метода — это просто один из его параметров.
Ну если вы придумали себе надуманные правила, то тогда да, правильно.
Вставил ремарку на этот счёт, спасибо.
Не очень понял, что конкретно "не совсем так". Да, можно объяснять по-другому, но что не совсем так то?
У Котлина качество статического анализа существенно ниже, да.
Егора наслушался что ли? :-)
А зачем делать метод нестатическим, когда он может быть статическим?
Кажется, в этом нет смысла. Эта строчка совершенно очевидно выполняется только при
cur == -1. Или сообщить, что "если бы это условие было не подif (cur == -1), оно не было бы всегда истинно"?Это натянуто. Ты в каждом методе, принимающем коллекцию, ожидаешь увидеть в ней null? Я вот нет. Иногда метод вправе ожидать каких-то гарантий относительно аргументов. Особенно приватный метод.
Я не слежу. Могли.
Мне это не нравится. Придётся компилировать всё равно с разными таргетами, но сливать класс-файлы в одно место. Можно запутаться или сломать какие-нибудь тулзы.
Дело моё, вы правы.
Почему хуже? XML внутри XML смотрится более органично, чем груви внутри XML. И это лучше, чем Gradle.kts, потому что менее кардинально и требует меньших усилий.
Я не проверял, но говорят, что если это делать как многомодульный мавен-проект, то IDE взлетит из коробки. А здесь надо специально распознавать нестандартный плагин, который хотя и неплох, но — посмотрим правде в глаза — имеет всего 16 звёзд на гитхабе.
Любая джава (и даже недоджава Андроида, я надеюсь), которая не в курсе этой фичи, будет просто игнорировать лишнюю строчку в манифесте и лишние файлы внутри META-INF. Если их не учитывать, всё остальное — вполне корректная Java-8-библиотека.
На вкус и цвет все фломастеры разные. Я уж скорее перейду на Gradle+Kotlin script, чем куски груви буду втыкать.
Можно попробовать установить только size, а потом вызвать легально trimToSize. Может быть существенно лучше.