Maven больше не нужен, теперь можно git репы прямо в gradle фигачить https://blog.gradle.org/introducing-source-dependencies

У 11 нет предпосылок быть сырой. А стороннее ПО имело много времени подготовиться к изменениям (основная опасность в переходе на 9). Какие баги поползут из разных мест, никогда не угадаешь, и версию java даже не обязательно менять. Я не предлагаю пойти обновлять прод, но не вижу причин не использовать 11 в менее критичных окружениях.

Странный вопрос. Вышла новая LTS версия с вагоном новых фич и улучшений в платформе. Какой профит продолжать сидеть на 8ке?

подождать полгодика пока ерли адоптеры баги все выловят

подождать полгодика пока ерли адоптеры баги все выловят

Maven больше не нужен, теперь можно git репы прямо в gradle фигачить https://blog.gradle.org/introducing-source-dependencies

Чтобы остаться без версионирования, как несчастные го программисты? Это очень нишевая фича

Через полгодика останется только платный саппорт от оракла, если я правильно картину понимаю. В OpenJDK бекпортить после появления следующей мажорной версии ничего не собираются, там фактически LTS-ок не будет, если, конечно, сторонние команды вроде AdoptOpenJDK не возьмутся за это.

конкретно задержку не скажу, но явно не надо лезть в это в первые дни если хочешь встретиться с наименьшим количеством трудностей при миграции

Стримов вроде вообще нет до сих пор.

Стримов вроде вообще нет до сих пор.

подождать полгодика пока ерли адоптеры баги все выловят

Как там дела у Gradle с Jigsaw? Когда я последний раз на эту тему гуглил, дела с мёртвой точки так и не сдвинулись.

Всеравно гемор, сабмодуль - лучший способ зашарить кусок приложения, который в активной разработке. Застрелишься тагами все покрывать, тогда проще через артифакт уже зашарить.

Мне не нравится думать о модификаторах коллекции, которые на каждую операцию все элементы копируют по одному. В этом смысле стримы же не будут много раз копировать.

Чтобы остаться без версионирования, как несчастные го программисты? Это очень нишевая фича

А кто может подсказать, зачем в Kotlin два идентичных интерфейса: Iterable и Sequence?

А кто может подсказать, зачем в Kotlin два идентичных интерфейса: Iterable и Sequence?

первый при вызове filter map и т.д. ,будет создавать промежуточные колекции

А у нас тут очередной EAP вышел: https://blog.jetbrains.com/idea/2018/09/intellij-idea-2018-3-eap-git-submodules-jvm-profiler-macos-and-linux-and-more/

там есть фиксы для корутин?)

Про неё можно писать мне, да

А кому можно написать про то, что при каждом индексировании файлов вылетает исключение в котлиновском плагине?) Интересно, я один такой или нет

Это или в kotli.in/issue или в слак

Ух, профайлер. После Visual Studio не хватало встроенного. Надеюсь, можно будет в отчёте выделить только свой код, без Спринга и сервера приложений.

Это будет. Но позже. Можешь создать issue пока :)

чтобы не писать на котлине в джава стиле - пара дней

А есть что почитать на эту тему, дабы осознать границу где кончается жава стиль?

тебе идея намекает...

на этот конкретный код по семантике не смотрите

takeIf не серый

тут нельзя прикреплять файлы большие (пытался 1.2мб видосик скинуть)

тут нельзя прикреплять файлы большие (пытался 1.2мб видосик скинуть)

у takeIf может быть nullable receiver

я и про то, что человек просто нулы юзает

@CommonName Int?, String? и т.д. котлин заботится что бы ты проверил не является ли переменая нул

он этого не понимает

в телеге глюк какой-то видос пропадает

@CommonName https://pastebin.com/

в телеге глюк какой-то видос пропадает

и как я сюда видос залью?

бот может удалять

бот может удалять

можно код

код не нужен

А, кстати да

нужен

@CommonName o1, o2 могуть быть нул, o1?.fun1(o2 ?: 0) https://kotlinlang.org/docs/reference/null-safety.html

ты это к чему вообще?