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

Обновить 3. KOTLIN IS СЕЙЧАС ОФИЦИАЛЬНО ПОДДЕРЖИВАЕТСЯ ДЛЯ РАЗВИТИЯ ANDROID. ПО GOOGLE. YAAAAAAAAS!

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

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


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

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

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

Новая цепочка инструментов Jack:
Джек (.java.jack.dex)

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

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

Ответ 1

Отказ от ответственности: я работаю над Jack

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

Ответ 2

@Pavel Dudka

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

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

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

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

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

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

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

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

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

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

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

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

  • Predexing

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

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

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

  • Переупаковка

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

  • Поддержка нескольких приложений

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

Недостатки:

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

Ответ 3

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

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


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

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

Jack and Jill Application Build

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

В соответствии с последним объявлением Google -

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

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

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

Источник: Будущая поддержка функций Java 8 Language на Android

Ответ 7

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

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

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

Так как @LukasBergstrom сказал, не будет никаких проблем с "застреванием в прошлом"; -)

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

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

Ответ 8

В соответствии с блог Kotlin откройте раздел "Новые возможности" 1.1-beta2:

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