Native Android App Development in Java

Native Android App Development in Java

Java on Android is not a default outdated choice. In several projects it's a conscious decision: corporate clients with internal Java stack standards, teams with deep Java EE expertise, legacy server-side integration on Spring Boot, where shared Java codebase reduces cognitive load. We develop native Android apps in Java where justified by project requirements.

With Android Studio Flamingo and AGP 8.x, Java development got proper Java 17 support via sourceCompatibility = JavaVersion.VERSION_17 in Gradle — lambdas, streams, Optional, var in local variables. This is not 2015 with Java 6 and anonymous classes for every OnClickListener.

Where Java Still Makes Sense

Corporate segment. Employee warehouse app integrating with SAP WM via SOAP service, where server team writes Java 11 — Kotlin adds operational overhead without real gain. Team reads single stack, bugs in shared business logic found faster.

Interop with C++ via JNI. Technically JNI works with Kotlin too, but Java signatures for native methods are clearer to most C++ developers writing NDK code. If app actively uses libc++ libraries for real-time audio or video processing — Java layer sometimes simpler to debug.

SDK development. If creating library for third-party developers, Java API clear to both Kotlin and Java consumers without @JvmStatic and @JvmOverloads annotations. Though for new SDK, Kotlin with proper annotations works equally well.

Technical Stack of Java Project

Architecture same — Clean Architecture + MVVM. ViewModel from androidx.lifecycle, LiveData or RxJava 3 for reactive data streams. RxJava in Java projects — full replacement for Kotlin Coroutines: Observable, Single, Completable, schedulers Schedulers.io() / AndroidSchedulers.mainThread(), operators flatMap, switchMap, debounce.

DI — Dagger 2 directly without Hilt wrapper, or Hilt (fully compatible with Java). In Java @Component and @Module more verbose, but Dagger codegen same.

Network — Retrofit 2 + OkHttp, like Kotlin projects. Retrofit works beautifully with Java: Call<T>, Callback<T>, or RxJava adapter via RxJava3CallAdapterFactory. Local storage — Room with DAO interfaces returning LiveData<T> or Flowable<T>.

UI: XML layouts with ViewBinding (not DataBinding — adds complexity without proportional benefit), RecyclerView with ListAdapter and DiffUtil. Jetpack Compose on Java officially not supported — limitation to accept consciously.

Typical Java Development Issues on Android

Callback hell with async chains. Without coroutines, sequence "authenticate → get profile → load settings" becomes three nested Callback. RxJava solves via flatMap chains, but requires proper understanding of Disposable and CompositeDisposable. Leaked Disposable on Activity destruction — common cause of crashes.

NullPointerException. Java lacks Kotlin's null-safety system. @Nullable / @NonNull annotations from androidx.annotation help, but don't guarantee compile-time check. Must use Optional<T> disciplinedly for methods that may return null, and Objects.requireNonNull() on public method entry.

Verbosity. Java ViewModel class with same functionality as Kotlin data class plus ViewModel takes 1.5–2 times more lines. Not performance issue — readability and writing speed issue. For complex screens with large state quantity, this noticeably hurts.

Process and Timeline

Development approach unchanged by language choice: requirements audit, architectural decision, CI from day one, Code Review on each PR, testing via JUnit4/JUnit5 + Mockito.

Java projects get slightly larger time buffer — language verbosity increases review and refactoring volume. Cost calculated individually after ТЗ analysis.

If language choice still open — discuss arguments applicable to your specific project. Sometimes correct answer is start in Java, migrate files year later as new features added. Kotlin and Java fully compatible in one module.