Опыт перевода Maven-проекта на Multi-Release Jar: уже можно, но ещё сложно

[sshikov]

>А красивое решение (по крайней мере, в теории)
После упоминания андроида эта фраза выглядит несколько странно. Не поясните? Это же фишка Java 9, как ее к андроиду-то прикручивать?

>Понятно, что любую проблему в Maven можно решить с помощью Ant
Любую проблему можно решить например при помощи gmaven — написав код на груви. Причем намного более быстро, гибко и удобно.

[tagir_valeev]

Не поясните? Это же фишка Java 9, как ее к андроиду-то прикручивать?

Любая джава (и даже недоджава Андроида, я надеюсь), которая не в курсе этой фичи, будет просто игнорировать лишнюю строчку в манифесте и лишние файлы внутри META-INF. Если их не учитывать, всё остальное — вполне корректная Java-8-библиотека.

Любую проблему можно решить например при помощи gmaven — написав код на груви

На вкус и цвет все фломастеры разные. Я уж скорее перейду на Gradle+Kotlin script, чем куски груви буду втыкать.

[sshikov]

>Я уж скорее перейду на Gradle+Kotlin script, чем куски груви буду втыкать.
Вообще-то вы предлагали Ant. Что намного хуже всего перечисленного :)

[tagir_valeev]

Почему хуже? XML внутри XML смотрится более органично, чем груви внутри XML. И это лучше, чем Gradle.kts, потому что менее кардинально и требует меньших усилий.

[sshikov]

Во-первых, груви не внутри xml, а где угодно, например в отдельном файле. Во-вторых, груви доступна нормальная модель POM, с которой можно делать практически что угодно. В третьих, груви мягко говоря, сильно лучше как язык (а ant ему при этом доступен через AntBuilder, если уж так захочется).

Ну в общем, дело ваше конечно, но я этим пользуюсь примерно с момента появления (а это где-то 2006 год наверное, точнее не помню, но даже на github проекту уже не менее 7 лет), и успешно переписал таким образом не один десяток antrun. Это вообще не кардинально, а вполне естественно.

[tagir_valeev]

Дело моё, вы правы.

[sshikov]

Да, у вас же библиотека… а у меня по большей части приложения. Это обычно разные потребности, собрать библиотеку под разные окружения, или собрать и развернуть приложение (тоже в разных окружениях). Не могу сказать, что сложнее — но у меня обычно применение ant заканчивается не начавшись, так как он просто не умеет многие вещи, типа REST, которые нужны. Поэтому сразу груви, либо в maven, либо уже в jenkins.

[CyberSoft]

Будет ли IntelliJ IDEA поддерживать mr-jar? В частности maven-проекты.

[tagir_valeev]

Я не проверял, но говорят, что если это делать как многомодульный мавен-проект, то IDE взлетит из коробки. А здесь надо специально распознавать нестандартный плагин, который хотя и неплох, но — посмотрим правде в глаза — имеет всего 16 звёзд на гитхабе.

[reforms]

Как идея, что думаете над таким подходом взамен multi-release jar?

package one.util.streamex;

class VersionSpecificDetector {

    static VersionSpecific get() {
        boolean j9 = System.getProperty("java.version", "").compareTo("1.9") > 0;
        if (j9) {
            try {
                Class<?> j9class = Class.forName("one.util.streamex.Java9Specific");
                return (VersionSpecific) j9class.newInstance();
            } catch(ClassNotFoundException | InstantiationException | IllegalAccessException mixe) {
                // Обработка ошибки должным образом
                // use j8 impl
            }
        }
        // j8
        return new Java8Specific();
    }
}

interface VerSpec {
    VersionSpecific VER_SPEC = VersionSpecificDetector.get();
}

Где VersionSpecific — это интерфейс

[aleksandy]

Так идея была в том, чтобы не пользоваться рефлексией, нет?

[tagir_valeev]

Мне это не нравится. Придётся компилировать всё равно с разными таргетами, но сливать класс-файлы в одно место. Можно запутаться или сломать какие-нибудь тулзы.

[godin]

то второй прогон просто затрёт результаты первог

У агента append=true по умолчанию и в твоем случае нет явного append=false, поэтому не затрет и можем упростить конфигурацию — github.com/amaembo/streamex/pull/206 ;)

[tagir_valeev]

Вставил ремарку на этот счёт, спасибо.

[Maccimo]

Виртуальная машина Андроида — это не Java, она не реализует даже спецификацию Java 7. В частности, там нет методов с полиморфной сигнатурой вроде invokeExact, и само присутствие этого вызова в байткоде всё ломает.

Вроде же MethodHandles в Android 8.0 (API level 26) добавили?

[tagir_valeev]

Я не слежу. Могли.