Функції Android N Java 8 (компілятор Джека) та інтероп Kotlin

Оновлення 3. Котлін зараз офіційно підтримується для розвитку андроїдів . НА GOOGLE. YAAAAAAAAS!

Оновлення 2 : Схоже, JetBrains дійсно зобов'язаний підтримувати Kotlin для Android в довгостроковій перспективі . Я щасливий користувач kotlin :).

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

=== ДЕКРЕКЦІОНОВАНИЙ НАПРЯМОК НАСТУПНО ===

Щойно Google випустив попередній перегляд майбутнього Android N з деякими цікавими функціями, найбільш помітною є часткова підтримка мови Java 8 . Це можливо завдяки новому ланцюжку інструментів Jack , над яким працює 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, який Джек / Джилл може імпортувати просто чудово.

@Pavel Дудка

Джек - це компілятор. Схожий на javac, але він робить дещо інше:

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

Але зачекайте! Що робити, якщо я включу в свій проект сторонні бібліотеки (яка надходить як колекція файлів .class)?

І ось тоді Джилл вступає в гру:

Jill може обробляти файли класів і перетворювати їх у спеціальний формат Jayce, який може бути використаний як вхід для компілятора Джека.

Тож тепер давайте відійдемо на секунду і подумаємо ... Що буде з усіма цими крутими плагінами, до яких ми так захопилися? Їм усім потрібні файли .class, а у компілятора Джека таких більше немає ...

На щастя, Джек надає кілька важливих для нас особливостей:

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

Переваги:

Джек підтримує мову програмування Java 1.7 та інтегрує додаткові функції, описані нижче.

• Випередження

  Під час створення файлу бібліотеки JACK .dex бібліотеки генерується та зберігається всередині файлу .jack бібліотеки як попередній декс. При компілюванні JACK повторно використовує попередній декс з кожної бібліотеки. Усі бібліотеки попередньо розміщені в декадах.

• Інкрементальне складання

  Поступова компіляція означає, що перекомпілюються лише ті компоненти, які торкнулися з моменту останньої компіляції, та їх залежності. Поступова компіляція може бути значно швидшою, ніж повна компіляція, коли зміни обмежуються лише обмеженим набором компонентів.

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

  Для повторної упаковки JACK використовує файли конфігурації jarjar.

• Підтримка Multidex

  Оскільки файли dex обмежені методами 65K, програми з методами понад 65K повинні бути розділені на кілька файлів dex. (Див. Розділ "Створення додатків із методами понад 65 Кб" для отримання додаткової інформації про мультидекс.)

Недоліки:

• Джек не підтримує API трансформації - не існує проміжного байт-коду Java, який ви можете змінити, тому деякі плагіни, про які я тут не згадував, перестануть працювати
• Наразі обробка анотацій не підтримується Джеком, тому якщо ви сильно залежаєте від таких бібліотек, як Dagger, AutoValue тощо, вам слід подумати двічі, перш ніж перейти на Jack. EDIT: Як вказував Джейк Уортон, Джек у N Preview підтримує обробку анотацій, але він ще не відкритий через Gradle.
• Детектори лінз, які працюють на рівні байт-коду Java, не підтримуються.
• Якоко не підтримується - ну, я особисто вважаю Якоко сумнівним (він насправді не показує те, що ви хочете бачити), тому можна повністю жити без нього
• Dexguard - корпоративна версія Proguard наразі не підтримується

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

Чи буде Джек чи Джилл повільнішими, все ще слід обговорювати. Команда Android сподівається, що джек буде швидшим, ніж поточний процес збирання, але наразі це не так

Крім того, Джек і Декс доступні у відкритому режимі, ніщо не заважає команді kotlin написати інструмент, що випускає файли .jack або .dex з вихідного коду kotlin.

ОНОВЛЕННЯ (16.03.2017)

На щастя, Джек мертвий, тому це не вплине на розробників Kotlin.

Якщо у Джека майбутнє, то ви застрягнете в минулому з Котліном. В даний час Джек не підтримує плагіни, які можуть компілювати джерело, що не є Java, у байт-код Dalvik. І навіть якщо це зробило JetBrains, потрібно було б додати новий бекенд до компілятора Kotlin, що не є тривіальною задачею. Тож вам доведеться використовувати Котлін з Джилл, і це буде щось дуже схоже на ланцюжок інструментів, яку ви зараз використовуєте.

Як ви бачите на зображенні нижче, навіть якщо неможливо явно відключити Джека, ви все одно зможете перетворити проект у проект бібліотеки, щоб використовувати Jill. І проектний додаток буде просто посилатися на цей проект бібліотеки.

Єдиний спосіб я бачу, як Котлін може працювати з Джеком, який, ймовірно, не буде реалізований, - це додавання Java-сервера в компілятор Kotlin, тобто бекенда, який генерує код Java, як Xtend . У цьому випадку код, сформований компілятором Kotlin, може бути оброблений Джеком як і будь-який інший код Java.

Але на даний момент ми не знаємо точно, що підтримає Джек, коли його випустять. Можливо, щось кардинально зміниться, і додавання Джека підтримку Котліна стане можливим.

Як сказано в публікації в блозі ( дорожня карта Котліна на Android ), що з’явилася сьогодні:

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

Тож Котлін врешті-решт підтримає Jack & Jill і отримає від цього користь.

Відповідно до останнього оголошення Google -

Ми вирішили додати підтримку мовних функцій Java 8 безпосередньо в поточний набір інструментів javac і dx, а також знехтуємо ланцюжок інструментів Jack. У цьому новому напрямку існуючі інструменти та плагіни, залежні від формату файлів класу Java, повинні продовжувати працювати. Просуваючись вперед, функції мов Java 8 будуть підтримуватися вбудованою системою Android. Ми прагнемо запустити це як частина Android Studio в найближчі тижні, і ми хотіли поділитися цим рішенням з вами рано.

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

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

Джерело: Підтримка мовної функції Java 8 на Android

Я вже знайшов цю публікацію в офіційному блозі Котліна :: Дорожня карта Котліна на Android

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

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

Так, як сказав @LukasBergstrom, з "застряганням у минулому" проблем не буде;

Ви також можете перевірити Redditдискусію, пов’язану з цією темою: Який статус Котліна з Джеком та Джилл?

Щасливе кодування.

Відповідно до блогу Котлін , випустіть розділ Нові функції 1.1-beta2:

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