Мы очень внимательно следим за планами Java, и на данный момент нам неизвестно о том, чтобы там планировались бы какие-то фичи, которые бы как-то конфликтовали с существующими или новыми фичами котлина. В том, что появляются фичи, которые предоставляют синтаксический сахар, аналогичный существующим фичам Kotlin (например, слово var), проблемы нет никакой вообще — .class-файлы остаются такими же, как были, и мы остаёмся с ними совместимыми так же, как раньше.
Сейчас нормального способа для этого нет (хотя я не помню, чтобы кто-то когда-то этого просил). В будущем мы планируем сделать для каждого диагностического сообщения страничку с документацией, в которой написано, в каких случаях оно возникает и как его правильно избегать, и тогда можно будет сделать навигацию с @Suppress на соответствующую страничку.
У нас есть официальные плагины для трёх IDE — IntelliJ IDEA, Eclipse и NetBeans. Если кто-то хочет программировать на Kotlin в другой среде — это их выбор, но мы не делаем ничего, чтобы как-то специально облегчить их жизнь.
Это не enum, потому что существуют диагностики, специфичные для конкретных бэкэндов, и если бы мы собрали их все в один enum, это создало бы очень неприятный coupling.
Причина, почему мы не публикуем эту информацию — во-первых, то, что сказал Андрей (диагностики регулярно меняются, разделяются и объединяются), а во-вторых, не предполагается, что кто-то будет писать аннотации @Suppress руками, а не через квикфикс. Если вы знаете конкретные случаи, в которых квикфикс на сообщении от компилятора недоступен или не работает — пожалуйста, сообщите нам, и мы это исправим.
Про «предоставить IDE» я имею в виду, что у нас есть экшн Tools | Kotlin | Configure Kotlin in Project, который автоматически вносит нужные изменения в ваши pom.xml.
А зачем в случае котлина следить за зависимостями внутри проекта? Компилятор котлина отлично умеет читать исходный код на java, поэтому то, что нужно запускать его перед запуском javac, никак вас не ограничивает в том, как именно у вас зависят друг от друга классы на kotlin и на java.
Сложность настройки — да, согласен, но это то, что нужно сделать один раз, причём не руками, а предоставить это IDE.
Компания JetBrains всячески одобряет выступления своих сотрудников на конференциях, но никак не контролирует содержимое докладов. Так что доклад-таки был Сашин, а не компании.
Видишь, есть такое объективно наблюдаемое явление: на Groovy под Android никто не программирует. Я не вижу ни заметного количества вопросов на StackOverflow от людей, которые сталкиваются с какими-то проблемами в этой связке, ни баг-репортов про то, что у кого-то что-то не работает в идее, ни блог-постов от людей, которые рассказывают, как у них круто получилось запрограммировать такое приложение и как всем тоже нужно бежать этим пользоваться. (Если я неправ, покажи, пожалуйста, ссылки.)
Почему это так — я не знаю. Возможно, все на самом деле прекрасно работает (и линтеры все проверяют, и рантайм маленький, и размер/скорость сгенерированного кода не хуже, чем в Java, и собирается все быстро). Но судя по первому пункту — подозреваю, что не все.
1) Алиасы для типов будут обязательно. Насколько я понимаю, сложностей там никаких не было — просто фича не казалась особенно приоритетной, а когда мы поняли, что казалась неправильно, нужно было уже стабилизироваться к релизу, а не добавлять новые фичи.
2) Пока никак, извините. Наверное, сделаем выключатель, чтобы все только в лог писалось.
Почему никак? final static оно будет само. Если вам вдруг зачем-то надо сериализовать фасадный класс (класс, в который помещаются декларации, находящиеся на уровне файла), вы можете повесить на него аннотацию Transient.
3) Я бы просто завел private val logger = LoggerFactory.getLogger(Klass::class.java) на уровне файла. Если сделать хелперную функцию, можно сократить это до private val logger = getLogger()
5) Для решения этой проблемы у нас придуман модификатор lateinit.
Опыт показывает, что обещать какие-то конкретные сроки — плохая идея. :) Как только, так сразу. 7 глава вот-вот появится в MEAP, две следующих уже почти готовы.
Сложность настройки — да, согласен, но это то, что нужно сделать один раз, причём не руками, а предоставить это IDE.
Почему это так — я не знаю. Возможно, все на самом деле прекрасно работает (и линтеры все проверяют, и рантайм маленький, и размер/скорость сгенерированного кода не хуже, чем в Java, и собирается все быстро). Но судя по первому пункту — подозреваю, что не все.
2) Пока никак, извините. Наверное, сделаем выключатель, чтобы все только в лог писалось.
5) Для решения этой проблемы у нас придуман модификатор lateinit.