[Из песочницы] Использование библиотек на Java 8 для приложений под Android с помощью Maven
Java 8 вышла в начале 2014 года, позволив Java-разработчикам использовать весьма удобные новшества для облегчения программирования тривиальных задач. Среди них — лямбда-выражения, ссылки на методы и конструкторы, реализация интерфейсных методов по умолчанию на уровне языка и JVM, а также использование Stream API на уровне стандартной библиотеки. К сожалению, вялость внедрения таких введений сказывается на поддержке этих средств на других программных платформах, ориентированных на Java. GWT и Android всё ещё не располагают официальной поддержкой хотя бы языковых средств Java 8. Впрочем, весенние SNAPSHOT-версии GWT 2.8.0 уже поддерживали лямбда-выражения. С Android дела обстоят иначе, так как здесь работа лямбда-выражений зависит не только от самого компилятора, но и от среды исполнения. Но с помощью Maven можно относительно просто решить проблему использования Java 8.
Так сложилось, что всю кодовую базу для своих проектов я держу на Maven из-за того, что:
- так сложилось исторически, не смотря на всю громоздкость pom.xml;
- есть возможность настраивать сборку в одном месте для модулей любого уровня вложенности;
- есть возможность использовать единый инструмент для сборки всей «вселенной» модулей.
Библиотеки общего назначения из этой кодовой базы написаны и подключаются к другим модулям таким образом, что их можно использовать как и в Java SE-проектах, так и в GWT или Android. Но ввиду того, что у Android плохо с Java 8, эти библиотеки и дальше остаются на Java 6 или 7, как и сами приложения из кодовой базы на Android. Тем не менее, после успешной работы с лямбдами в GWT, появилось желание мигрировать всю свою кодовую базу на Java 8. Скомпилировать и установить в локальный репозиторий свои библиотеки не составляет большого труда:
org.apache.maven.plugins
maven-compiler-plugin
1.8
После установки библиотек в локальный репозиторий можно, в принципе, собирать само приложение. Но в процессе «dex»-ирования возникнет следующая ошибка:
[INFO] UNEXPECTED TOP-LEVEL EXCEPTION:
[INFO] com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or version (0034.0000)
[INFO] at com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassFile.java:472)
[INFO] at com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)
[INFO] at com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388)
[INFO] at com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.java:251)
[INFO] at com.android.dx.command.dexer.Main.processClass(Main.java:665)
[INFO] at com.android.dx.command.dexer.Main.processFileBytes(Main.java:634)
[INFO] at com.android.dx.command.dexer.Main.access$600(Main.java:78)
[INFO] at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:572)
[INFO] at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)
[INFO] at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)
[INFO] at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)
[INFO] at com.android.dx.command.dexer.Main.processOne(Main.java:596)
[INFO] at com.android.dx.command.dexer.Main.processAllFiles(Main.java:498)
[INFO] at com.android.dx.command.dexer.Main.runMonoDex(Main.java:264)
[INFO] at com.android.dx.command.dexer.Main.run(Main.java:230)
[INFO] at com.android.dx.command.dexer.Main.main(Main.java:199)
[INFO] at com.android.dx.command.Main.main(Main.java:103)
[INFO] ...while parsing foo/bar/FooBar.class
Эта ошибка означает, что dx
не может обработать класс-файлы, сгенерированные компилятором Java 8. Поэтому подключаем Retrolambda, что, по идее, должно исправить ситуацию:
net.orfjackal.retrolambda
retrolambda-maven-plugin
2.0.6
process-classes
process-main
process-test
true
1.6
К сожалению, foo/bar/FooBar.class
принадлежит библиотеке и ошибка не устраняется. retrolambda-maven-plugin
не может справиться с задачей инструментирования библиотек приложения в принципе, так как может обработать класс-файлы только для текущего модуля (инача для этого нужно было бы обработать класс-файлы прямо в репозитории). То есть приложение не может использовать Java 8 библиотеки, но может использовать Java 8 код только в текущем модуле. Это можно исправить следующим образом:
- распаковать все Java 8 зависимости в директорию, где можно провести «даунгрейд» байткода;
- обработать байткод текущего модуля одновременно с байткодом распакованных зависимостей;
- собрать DEX-файл и APK-файл с исключением модулей, которые уже находятся в обработанном состоянии.
Текущая реализация android-maven-plugin
запускает dx
с указанием всех зависимостей, что ещё более усугубляет инструментирование зависимостей на Java 8. Вот что примерно запускает android-maven-plugin
:
$JAVA_HOME/jre/bin/java
-Xmx1024M
-jar "$ANDROID_HOME/sdk/build-tools/android-4.4/lib/dx.jar"
--dex
--output=$BUILD_DIRECTORY/classes.dex
$BUILD_DIRECTORY/classes
$M2_REPO/foo1-java8/bar1/0.1-SNAPSHOT/bar1-0.1-SNAPSHOT.jar
$M2_REPO/foo2-java8/bar2/0.1-SNAPSHOT/bar2-0.1-SNAPSHOT.jar
$M2_REPO/foo3-java8/bar3/0.1-SNAPSHOT/bar3-0.1-SNAPSHOT.jar
Здесь все три Java 8 библиотеки отправляются на обработку dx
. В самом плагине не существует возможности управлять фильтром зависимостей, которые нужно передать в dx
. Почему важно иметь возможность управлять таким фильтром? Можно предположить, что некоторые зависимости уже находятся в более удобном для обработки, чем репозиторий артефактов, месте. Например, в ${project.build.directory}/classes
. Именно здесь и можно обработать Java 8 зависимости с помощью retrolambda-maven-plugin
.
Для Maven существует плагин, которым можно распаковать зависимости в нужную директорию, что позволит обработать нужные зависимости нужным образом. Делается это следующим образом:
org.apache.maven.plugins
maven-dependency-plugin
2.10
process-classes
unpack-dependencies
runtime
foo1-java8,foo2-java8.foo3-java8
${project.build.directory}/classes
Я добавил в форк android-maven-plugin
поддержку нескольких опций для управления фильтром зависимостей. Среди них — фильтрация и включение (excludes
и includes
) по идентификатору группы, идентификатору артефакта и версии. Идентификаторы артефактов и их версии можно не указывать. Все элементы, идентифицирующие артефакт или группу артефактов, должны быть разделены двоеточием. Тем не менее, попробовать Java 8 и Java 8-замисимости в Android-приложении можно, хотя запрос на слияние в родительский репозиторий пока не принят. Для этого сначала нужно собрать сам форк плагина:
# Ревизия последней синхронизации с upstream оригинального плагина:
PLUGIN_REVISION=a79e45bc0721bfea97ec139311fe31d959851476
# Клонируем форк:
git clone https://github.com/lyubomyr-shaydariv/android-maven-plugin.git
# Убеждаемся в том, что используем проверенную ревизию:
cd android-maven-plugin
git checkout $PLUGIN_REVISION
# Собираем плагин:
mvn clean package -Dmaven.test.skip=true
# Переходим в target, где будем готовиться к установке форка в Maven-репозиторий:
cd target
cp android-maven-plugin-4.3.1-SNAPSHOT.jar android-maven-plugin-4.3.1-SNAPSHOT-$PLUGIN_REVISION.jar
# Исправляем pom.xml:
cp ../pom.xml .
sed -i "s/4.3.1-SNAPSHOT<\\/version>/4.3.1-SNAPSHOT-$PLUGIN_REVISION<\\/version>/g" pom.xml
# Обновляем дескриптор плагина:
unzip android-maven-plugin-4.3.1-SNAPSHOT-$PLUGIN_REVISION.jar META-INF/maven/plugin.xml
sed -i "s/4.3.1-SNAPSHOT<\\/version>/4.3.1-SNAPSHOT-$PLUGIN_REVISION<\\/version>/g" META-INF/maven/plugin.xml
zip android-maven-plugin-4.3.1-SNAPSHOT-$PLUGIN_REVISION.jar META-INF/maven/plugin.xml
# Устанавливаем, собственно, плагин:
mvn org.apache.maven.plugins:maven-install-plugin:2.5.2:install-file -DpomFile=pom.xml -Dfile=android-maven-plugin-4.3.1-SNAPSHOT-$PLUGIN_REVISION.jar
После всего этого можно настроить pom.xml
своего приложения:
org.apache.maven.plugins
maven-compiler-plugin
3.2
1.8
org.apache.maven.plugins
maven-dependency-plugin
2.10
process-classes
unpack-dependencies
runtime
foo1-java8,foo2-java8.foo3-java8
${project.build.directory}/classes
net.orfjackal.retrolambda
retrolambda-maven-plugin
2.0.6
process-classes
process-main
process-test
true
1.6
com.simpligility.maven.plugins
android-maven-plugin
4.3.1-SNAPSHOT-a79e45bc0721bfea97ec139311fe31d959851476
package
${project.basedir}/src/main/android/AndroidManifest.xml
${project.basedir}/src/main/android/assets
${project.basedir}/src/main/android/res
19
true
true
${project.basedir}/proguard.conf
foo1-java8
foo2-java8
foo3-java8
true
net.sf.proguard
proguard-base
5.2.1
runtime
Вот, собственно, и всё. Следует отметить, что такой подход подразумевает использование только языковых средств Java 8, а не стандартных библиотек типа Stream API. Хочу также подчеркнуть, что используя данную методику можно не только подружить Android с приложениями и их зависимостями, написанными на Java 8, но и обрабатывать байт-код сторонних зависимостей как заблагорассудится. Не могу сказать, что мне полностью нравится это решение с точки зрения элегантности.
Возможно, в других системах сборки проектов всё значительно проще. Я даже не знаю, может ли это быть проще в самом Maven, и не является ли вся эта поделка частью велосипедостроения, но, тем не менее, мне было интересно заставить Maven сделать то, что от него требуется.