Немного о том, на чём я пишу свою диагностическую программу
SZ Viewer.
Практически весь код написан на Scala 2.11 за исключением очень небольшого кусочка на Java. Используется старая версия Scala 2.11.12 (релиз ноября 2017 года), поскольку это последняя версия, которая генерирует байт-код версии до Java 8 (если быть точнее, Java 6). Это критически важно для использования кода под Android, который хоть и
поддерживает Java 8+ возможности, но весьма ограниченно (нападки Oracle на Google вышли боком). С более свежими Scala 2.12+ есть проблемы при сборке под Android через Java 8+ байт-код, что иногда обходят компиляцией в нативный код - но это так себе вариант (по многим причинам).
SZ Viewer - это единственный актуальный проект, в котором использую такую старую Scala, в других перешёл как минимум на Scala 2.13 или на Scala 3.
В целом к Scala я отношусь очень хорошо, пишу в основном на ней с 2010 года (перед этим в основном писал на Java, а перед этим на C и C++, но это было довольно давно). Сейчас на Java стараюсь вообще не писать, только там, где это необходимо.
В качестве IDE уже много лет (ещё с времён Java и работы под OS/2) использую IntelliJ IDEA (сейчас бесплатной Community версии).
1. Универсальная часть код
Эта часть кода используется одновременно и в Android, и в PC версиях. Реализует всю работу с протоколами и абстрактную работу с ELM327. Содержит ~14400 строк кода (здесь и далее подсчёт при помощи cloc) исключительно на Scala, здесь нет Java кода.
Собирается под Java 7, использует только стандартные библиотеки Java 7 и Scala 2.11, других зависимостей нет.
2. Часть кода для PC (Windows, Linux, macOS)
Часть кода, которая используется в версиях для PC. Сборки для Windows, Linux, macOS делаются на одном и том же коде. Содержит ~13800 строк кода на Scala и ~500 строк на Java.
Собирается под Java 7, есть зависимость от сторонних библиотек.
Для доступа к нативному коду (работа с адаптерами, портами и т.д.) используется
JNA (в том числа и JNA Platform), Java код как раз нужен для взаимодействия с JNA (для большей предсказуемости результата). Есть желание перейти на
JNR, но тогда требуется сборка как минимум под Java 8, что пока недоступно.
Для сжатия логов
теперь используется
XZ Utils, а для старых логов использовался стандартный Gzip, но он гораздо менее эффективный.
В совсем ранних версиях программы
появились графики, для отрисовки которых используется
GRAL. Мне эта отрисовка совершенно не нравится, но она сохранилась, поскольку мне было лень делать другую. Возможно, она будет заменена на самодельную.
Сборка для Windows идёт с чуть подрезанной 32-битной Oracle Java 8 (202 - последняя с лицензией BCL, 2018 год). Это нужно для работы под Windows XP, а 32-битность нужна и для доступа драйверов
адаптеров J2534 (Pass-Thru). exe-файл для запуска собран, кстати, при помощи Go (совсем крохотная программка).
Сборки для Linux и macOS идут с достаточно свежей 64-битной OpenJDK 17 (Eclipse Temurin), но в сокращённом варианте (только требуемые модули).
Сборка для macOS - это вообще сомнительное дело. Сейчас для обхода необходимой подписи используется тот факт, что сам OpenJDK подписан, а command-файл подписывать не надо (только нужен первый запуск через Open в меню). Но с учётом политики Apple нужно либо уходить в коммерческое распространение, чем и окупать затраты на аккаунт и подпись. Либо, наоборот, в open source и распространять (для узкого круга) через
homebrew. Для бесплатной, но закрытой программы в этом будущем места нет.
Как уже
писал, для Linux вполне реально сделать свой репозиторий (с deb, успешный опыт есть) для установки через dpkg/APT, если это кому-то было бы нужно. А так лично мне проще скачать tarball, распаковать и запустить программу без замусоривания системы.
3. Часть кода для Android
Часть используется только для Android-приложения, довольно небольшая. Содержит ~3200 строк кода на Scala, здесь Java кода нет.
Как уже
упоминал, собирается при помощи старой версии sbt 0.13 со старым плагином
org.scala-android (1.7.10 от сентября 2017 года - это последняя версия). Но потом ещё требуется некоторая ручная доводка APK (связанная с подписью) для нынешних требований Google Play.
Задана минимальная версия Android API 14 (Android 4.0.1 – 4.0.2) и целевая версия 30 (Android 11). Требуется переход на целевую версию 31 (Android 12), но пока
не сделан.
Используются старые версии 27.1 (2018 год) support-библиотеки. Уж не помню почему, но с 28.0 были проблемы. Переезд на AndroidX нужен, но невозможен технически при используемой системе сборки.
4. Перспективы
Возможно, что часть кода для PC в будущем будет собираться не под Java 7, а под Java 8. Это позволит хотя бы попробовать JNR вместо JNA. JNR теоретически должен быть быстрее.
Общая часть останется под Java 7 - для использования в сборке под Android.
Android часть, видимо, рано или поздно придётся переписать под современную систему сборки (gradle) и AndroidX. Писать на Java не очень хочется. Очень уж устаревший и громоздкий язык. Да, в новых версиях Java сделаны изменения, но под Android они недоступны (опять привет, Oracle). Поэтому придётся использовать Kotlin, хоть он мне и не особо нравится.
Я уже проверил, общая часть кода на Scala 2.11 доступна из Kotlin при сборке под Android, хоть, конечно, возможности API урезаются (хотя бы из-за отсутствия в Kotlin нормального Maybe/Option/Optional-типа).
Переписывание же общей части кода и части кода для PC на Kotlin очень малоинтересно, хотя в проекте накопилось много неправильно и не совсем корректно сделанных вещей, исправление которых требует столько изменений, что может показаться, что проще переписать.
Вообще, для подобного проекта я воспринимаю только языки со статической типизацией. Из таковых кроме Scala мне интересны, пожалуй, только Rust и Haskell.
Но Haskell интересен больше теоретически (для повышения уровня культуры, тем более влияние Haskell сильно ощущается в Scala), а вот Rust вполне практически. В принципе, я не против в будущем переписать SZ Viewer на Rust, но написание
частей Android-приложения на Rust хоть
и возможно, но очень-очень условно.
Кроме того, нужно смотреть, насколько реально сейчас собирать на Rust код, который будет работать под 32-битной Windows XP. То, что я сходу попробовал, на MSVC toolchain вообще не запускается, а на GNU toolchain запускается, но ругается то на одну DLL, то на другую. Надо разбираться. Сейчас тенденция такая, что и Windows 7 скоро за бортом останется. В этом плане текущая сборка SZ Viewer для Windows весьма ретроградная.