Нативна розробка 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 повністю сумісні в одному модулі.