Android N Java 8 (компилятор Jack) и Kotlin interop

Обновление 3. КОТЛИН СЕЙЧАС ОФИЦИАЛЬНО ПОДДЕРЖИВАЕТСЯ ДЛЯ РАЗВИТИЯ АНДРЕЙ. ПО GOOGLE. YAAAAAAAAS!

Обновление 2 : похоже, что JetBrains действительно привержен поддержке Kotlin для Android в долгосрочной перспективе . Я счастливый клиент kotlin :).

Обновление : Хади Харири, из JetBrains, упомянул, что собирается опубликовать некоторую информацию по этой теме . Я обновлю этот пост, как только они это сделают.

=== УНИЧТОЖЕННЫЙ СЛУЧАЙ ===

Google только что выпустил предварительный просмотр для предстоящего Android N с некоторыми интересными функциями, наиболее заметным из которых является частичная поддержка языка Java 8 . Это возможно благодаря новой инструментальной цепочке Джека, над которой работает Google.

Текущая инструментальная цепочка с использованием javac или kotlinc :
javac ( .java -> .class ) -> dx ( .class -> .dex )
kotlinc ( .kt -> .class ) -> dx ( .class -> .dex )

Новая цепочка Jack Jack:
Джек ( .java -> .jack -> .dex )

Я предполагаю, что Google будет продвигаться вперед, чтобы заставить Джек использовать инструментальную цепочку по умолчанию для разработки Android. Обновление: теперь Джек устарел . Яс.

Мой вопрос в том, как этот новый инструментарий повлияет на меня, в будущем, как пользователя kotlin для разработки Android? «Я застрял бы в прошлом»?

отказ от ответственности: я работаю над Джеком

Это не повлияет на вас. Компилятор Kotlin создает байт-код Java 6, который Jack / Jill может импортировать просто отлично.

@Pavel Dudka

Джек – это компилятор. Подобно javac, но это немного другое:

введите описание изображения здесь

Как вы можете видеть, Джек компилирует исходный код Java прямо в файл Dex! У нас больше нет промежуточных * .class файлов, поэтому инструмент dx не нужен!

Но ждать! Что делать, если я включаю стороннюю библиотеку в свой проект (который поставляется в виде коллекции файлов .class)?

И вот когда Джилл начинает играть:

введите описание изображения здесь

Jill может обрабатывать файлы классов и преобразовывать их в специальный формат Jayce, который может использоваться как вход для компилятора Jack.

Так что теперь давайте отступим на секунду и подумаем … Что будет со всеми этими классными плагинами, к которым мы так привыкли? Все они нуждаются в файлах .class, а у компилятора Jack больше нет таких …

К счастью, Джек предоставляет некоторые из тех важных для нас функций из коробки:

  • Retrolambda – не понадобится. Джек может правильно обращаться с лямбдами
  • Proguard – теперь он запекается в Джека, поэтому вы все еще можете использовать обфускацию и минимизацию

Преимущества:

Джек поддерживает язык программирования Java 1.7 и интегрирует дополнительные функции, описанные ниже.

  • Predexing

    При создании файла библиотеки JACK библиотека .dex библиотеки генерируется и хранится внутри файла библиотеки .jack в виде pre-dex. При компиляции JACK повторно использует pre-dex из каждой библиотеки. Все библиотеки предварительно дешированы.

  • Инкрементальная компиляция

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

  • смена упаковки

    JACK использует файлы конфигурации jarjar для переупаковки.

  • Поддержка Multidex

    Поскольку файлы dex ограничены методами 65K, приложения с более чем 65K-методами должны быть разделены на несколько файлов dex. (См. «Создание приложений с более чем 65K-методами» для получения дополнительной информации о мультидексе.)

Недостатки:

  • Transform API не поддерживается Jack – нет промежуточного Java-байт-кода, который вы можете изменить, поэтому некоторые плагины, которые я не упоминал здесь, перестанут работать
  • Обработка аннотаций в настоящее время не поддерживается Джеком, поэтому, если вы сильно зависите от таких библиотек, как Dagger, AutoValue и т. Д., Вы должны подумать дважды, прежде чем переключиться на Jack. EDIT: Как отметил Джейк Уортон, Jack in N Preview поддерживает поддержку обработки аннотаций, но пока он не показывается через Gradle.
  • Lint-детекторы, которые работают на уровне байт-кода Java, не поддерживаются.
  • Jacoco не поддерживается – хорошо, я лично считаю Jacoco сомнительным (он действительно не показывает, что вы хотите видеть), поэтому он может полностью жить без него
  • Dexguard – корпоративная версия Proguard в настоящее время не поддерживается

ОБНОВЛЕНИЕ (03/16/2017)

К счастью, Джек мертв, и это не повлияет на разработчиков Kotlin.


Если Джек – это будущее, тогда вы застрянете в прошлом с Котлином. В настоящее время Джек не поддерживает плагины, которые могут компилировать источник не Java в байт-код Dalvik. И даже если бы JetBrains потребовалось бы добавить новый бэкэнд в компилятор Kotlin, который не является тривиальной задачей. Поэтому вам придется использовать Kotlin с Джилл, и это будет нечто очень похожее на инструментальную цепочку, которую вы используете сейчас.

Как вы можете видеть на изображении ниже, даже если невозможно явно отключить Джек, вы все равно сможете преобразовать проект в проект библиотеки, чтобы использовать Jill. И проект приложения будет просто ссылаться на этот проект библиотеки.

Создание приложения Jack and Jill

Единственный способ, которым я вижу, как Kotlin может работать с Джеком, который, вероятно, не будет реализован, добавляет бэкэнд Java к компилятору Kotlin, то есть бэкэнд, который генерирует Java-код, такой как Xtend . В этом случае код, созданный компилятором Kotlin, может обрабатываться Джеком как любой другой Java-код.

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

Google не собирается подталкивать Джека как инструмент по умолчанию, но Jack and Jill .
Компиляция файлов .class в dex с Джилл здесь, чтобы остаться. В противном случае вы можете попрощаться с библиотеками jar / aar.

Будут ли Джек или Джилл медленнее, все еще обсуждается. Команда Android надеется, что jack будет быстрее, чем текущий процесс сборки, но сейчас это не так.

Кроме того, Jack и Dex доступны в открытом доступе, ничто не мешает команде kotlin писать инструмент, из которого можно вывести файлы .jack или .dex из исходного кода kotlin.

Как сказано в сообщении в блоге ( «Дорожная карта Android» Котлина ), появившемся сегодня:

В настоящее время есть некоторые проблемы, которые мешают Джеку правильно обрабатывать байт-код, созданный Котлином ( 196084 и 203531 ), но мы планируем работать вместе с командой Google, чтобы либо решить проблемы, либо предложить обходные пути на нашей стороне. Как только это будет сделано, мы сможем перевести только измененные файлы классов с помощью Jill во время инкрементной компиляции, а не переводить все файлы классов каждый раз (что является единственным возможным поведением в старой утилите Android).

Поэтому Котлин в конечном итоге поддержит Джека и Джилла и получит от него выгоду.

Согласно последнему объявлению Google –

Мы решили добавить поддержку языковых функций Java 8 непосредственно в текущий набор инструментов javac и dx, а также отказаться от инструментальной привязки Jack. В этом новом направлении существующие инструменты и плагины, зависящие от формата файла классов Java, должны продолжать работать. Двигаясь вперед, функции языка Java 8 будут поддерживаться системой Android. Мы собираемся запустить это как часть Android Studio в ближайшие недели, и мы хотели бы поделиться этим решением с вами на ранней стадии.

Сначала мы тестировали добавление поддержки Java 8 через инструментальную цепочку Jack. Со временем мы поняли, что стоимость переключения на Джек была слишком высокой для нашего сообщества, когда мы рассматривали обработчики аннотаций, анализаторы байт-кода и переписывающие устройства. Благодарим вас за то, что вы попробовали инструмент Jack toolchain и дали нам отличную обратную связь. Вы можете продолжить использовать Jack для создания кода Java 8 до тех пор, пока мы не выпустим новую поддержку. Миграция с Джека должна выполняться практически без работы.

Таким образом, нам не нужно беспокоиться о том, что jack toolchain становится стандартной toolchain для разработки Android. Вы можете продолжать использовать kotlin или использовать обычный набор инструментов javac / dx.

Источник: будущее Java 8 Язык Поддержка функций на Android

Я уже нашел это сообщение в блоге из официального блога Kotlin :: Дорожная карта Android от Kotlin

Там вы найдете часть, которая говорит, что:

Следующее, что мы планируем сделать для повышения производительности Android, – это интеграция с новой технологической цепочкой Jack и Jill от Android. В настоящее время есть некоторые проблемы, которые мешают Джеку правильно обрабатывать байт-код, созданный Котлином ( 196084 и 203531 ), но мы планируем работать вместе с командой Google, чтобы либо решить проблемы, либо предложить обходные пути на нашей стороне. Как только это будет сделано, мы сможем перевести только измененные файлы классов с помощью Jill во время инкрементной компиляции, а не переводить все файлы классов каждый раз (что является единственным возможным поведением в старой утилите Android).

Так как @LukasBergstrom сказал, не будет никаких проблем с «застреванием в прошлом» 😉

Вы также можете проверить обсуждение Reddit связанное с этой темой: Каков статус Котлина с Джеком и Джиллом?

Счастливое кодирование.

Согласно блогу Kotlin , отпустите раздел «Новые возможности» 1.1-beta2:

Поддержка создания проектов Android, когда включена инструментальная цепочка Jack (jackOptions {true});