Нативная разработка Android-приложения на Java
Java на Android — не устаревший выбор по умолчанию. В ряде проектов это осознанное решение: корпоративные клиенты с внутренними стандартами Java-стека, команды с глубокой экспертизой в Java EE, интеграция с legacy-серверной частью на Spring Boot, где общая кодовая база на Java снижает когнитивную нагрузку. Мы разрабатываем нативные Android-приложения на Java там, где это оправдано требованиями проекта.
С Android Studio Flamingo и AGP 8.x Java-разработка получила нормальную поддержку Java 17 через sourceCompatibility = JavaVersion.VERSION_17 в Gradle — лямбды, streams, Optional, var в локальных переменных. Это не 2015 год с Java 6 и анонимными классами на каждый OnClickListener.
Где Java всё ещё имеет смысл
Корпоративный сегмент. Приложение для сотрудников склада, которое интегрируется с SAP WM через SOAP-сервис, где серверная команда пишет на Java 11 — там Kotlin добавит операционный оверхед без реальной выгоды. Команда читает единый стек, баги в общей бизнес-логике находятся быстрее.
Interop с C++ через JNI. Технически JNI работает и с Kotlin, но Java-сигнатуры для native-методов понятнее большинству C++-разработчиков, которые пишут NDK-код. Если приложение активно использует libc++-библиотеки для обработки аудио или видео в реальном времени — Java-прослойка иногда проще в отладке.
SDK-разработка. Если создаётся библиотека для сторонних разработчиков, Java API понятен как Kotlin-, так и Java-потребителям без аннотаций @JvmStatic и @JvmOverloads. Хотя для новых SDK Kotlin с правильными аннотациями работает не хуже.
Технический стек Java-проекта
Архитектура та же — Clean Architecture + MVVM. ViewModel из androidx.lifecycle, LiveData или RxJava 3 для реактивных потоков данных. RxJava в Java-проектах — полноценная замена Kotlin Coroutines: Observable, Single, Completable, планировщики Schedulers.io() / AndroidSchedulers.mainThread(), операторы flatMap, switchMap, debounce.
DI — Dagger 2 напрямую, без Hilt-обёртки, или Hilt (он полностью совместим с Java). В Java @Component и @Module многословнее, но кодогенерация Dagger та же.
Сеть — Retrofit 2 + OkHttp, как и в Kotlin-проектах. Retrofit прекрасно работает с Java: Call<T>, Callback<T>, или RxJava-адаптер через RxJava3CallAdapterFactory. Локальное хранилище — Room с DAO-интерфейсами, которые возвращают LiveData<T> или Flowable<T>.
UI: XML layouts с ViewBinding (не DataBinding — он добавляет сложность без пропорциональной пользы), RecyclerView с ListAdapter и DiffUtil. Jetpack Compose на Java официально не поддерживается — это ограничение, которое нужно принимать осознанно.
Типичные проблемы Java-разработки на Android
Callback hell при асинхронных цепочках. Без корутин последовательность «авторизация → получить профиль → загрузить настройки» превращается в три вложенных Callback. RxJava решает это через flatMap-цепочки, но требует правильного понимания Disposable и CompositeDisposable. Утечка Disposable при уничтожении Activity — распространённая причина крашей.
NullPointerException. Java не имеет системы null-safety Kotlin. @Nullable / @NonNull аннотации из androidx.annotation помогают, но не гарантируют проверку в compile-time. Придётся дисциплинированно использовать Optional<T> для методов, которые могут вернуть null, и Objects.requireNonNull() на входе публичных методов.
Многословность. Java-класс ViewModel с тем же функционалом, что Kotlin data class + ViewModel, занимает в полтора-два раза больше строк. Это не проблема производительности — это проблема читаемости и скорости написания. Для сложных экранов с большим числом состояний это ощутимо.
Процесс и сроки
Подход к разработке не меняется от выбора языка: аудит требований, архитектурное решение, CI с первого дня, Code Review на каждый PR, тестирование через JUnit4/JUnit5 + Mockito.
| Тип проекта | Оценка |
|---|---|
| MVP с 5-8 экранами и REST API | 5-7 недель |
| Корпоративное приложение с интеграциями | 10-14 недель |
| Библиотека/SDK для сторонних разработчиков | 4-8 недель |
На Java-проектах закладываем чуть больший запас времени — многословность языка увеличивает объём ревью и рефакторинга. Стоимость рассчитывается индивидуально после анализа ТЗ.
Если выбор языка ещё не закрыт — обсудим аргументы применительно к вашему конкретному проекту. Иногда правильный ответ — начать на Java, а через год мигрировать файлы по мере добавления новых фич. Kotlin и Java полностью совместимы в одном модуле.