העברת אפליקציות אנדרואיד מ-Java ל-Kotlin

אנחנו רואים צוותים עם עשרות אלפי שורות של Java שנתקעים במעבר ל-Kotlin. גוגל הכריזה רשמית ש-API חדשים של Jetpack—Paging 3, DataStore, WorkManager עם coroutines, Jetpack Compose—יש להם משטח ראשוני של Kotlin יוזמת Kotlin-first של גוגל. טכנית אפשר לקרוא להם מ-Java, אבל עם כל כך הרבה מתאמים ועקיפות שהפרודוקטיביות יורדת. בפרויקט טיפוסי, 30% מהקוד הם getters, setters, ובדיקות null; במהלך המעבר ל-Kotlin, הנפח הזה קטן פי 2–3. אבל הממיר האוטומטי של Android Studio נותן רק תרגום תחבירי, לא ארכיטקטוני. אנחנו עוזרים לכם לבצע מעבר בלי לעצור את הפיתוח ובלי לאבד יציבות. צרו קשר להערכת עבודה מקדימה.

למה אי אפשר פשוט ללחוץ "המר קובץ Java ל-Kotlin"

Android Studio יכול להמיר קבצי Java ל-Kotlin אוטומטית. התוצאה טכנית מתקמפלת. אבל זה לא Kotlin; זה תעתיק של Java לתחביר Kotlin:

• var בכל מקום במקום val — אין immutability
• !! על כל הפניה null — NullPointerException פשוט שונה לשם KotlinNullPointerException
• אין data classes — אותם POJOs עם getters דרך field.get()
• object ו-companion objects חסרים — מתודות סטטיות מרחפות כ-extensions
• אין coroutines — SAM conversion או RxJava נשארים
• Lambdas נראים כמו lambdas של Java 8, אבל בלי finalize() לממשקים מותאמים אישית

קוד כזה לא נותן אף אחד מהיתרונות של Kotlin, רק מוסיף בלבול. הממיר האוטומטי הוא כלי להתחיל, לא לסיים.

איך נראה מעבר נכון

מלאי לפני שמתחילים

השלב הראשון הוא ביקורת מלאה של בסיס הקוד: מספר מחלקות לפי סוג (Activity, Fragment, ViewModel, Repository, Model, Util), כיסוי בדיקות, רשימת מודולים בפיתוח פעיל לעומת יציבים, תלות בדפוסים שאינם תואמים ל-Kotlin (לדוגמה, static, דפוסים מסוימים עם מחלקות פנימיות POJO).

בהתבסס על הביקורת, אנחנו בונים תוכנית: אילו קבצים להמיר קודם, באילו לגעת אחרונים, ואיפה פיתוח מקביל ב-Java נמשך במהלך המעבר.

אסטרטגיית Bottom-Up

התחילו עם מחלקות שאין להן תלות ב-Android: מודלי נתונים, כלי עזר, קבועים. data class של Java עם שדות, getters ו-setters הופך ל-equals() של Kotlin — תועלת מיידית: hashCode(), toString(), copy(), // Было: Java POJO, 60 строк с геттерами/сеттерами // Стало: data class UserProfile( val id: Long, val name: String, val email: String, val avatarUrl: String? = null ) בחינם.

// Было: Java POJO, 60 строк с геттерами/сеттерами
// Стало: data class UserProfile(
    val id: Long,
    val name: String,
    val email: String,
    val avatarUrl: String? = null
)

אז עוברים לשכבת ה-Repository. ההחלטה המרכזית כאן היא איך לטפל בקוד אסינכרוני. אם הפרויקט השתמש ב-RxJava, יש שתי דרכים: להשאיר את RxJava (Kotlin עובד מצוין עם RxJava) או לעבור ל-coroutines + Flow. הדרך השנייה טובה יותר אסטרטגית אבל יקרה יותר ברגע. עבור repositories בפיתוח פעיל, אנחנו הולכים עם coroutines; עבור מודולים יציבים ללא שינויים, אנחנו משאירים RxJava עד הרפקטורינג הגדול הבא.

מעבר מ-LiveData ל-StateFlow

שכבת ViewModel: LiveData → StateFlow + SharedFlow. זה לא חובה; LiveData עובד גם ב-Kotlin, אבל StateFlow מתנהג בצורה צפויה יותר — אין קסם עם LifecycleOwner, אין דליפות observeForever, אין בלבול בין setValue ל-postValue. ההחלפה מתרחשת בשלושה שלבים: שינוי סוג השדה, התאמת הרשמות ב-fragments, עדכון בדיקות.

Activity ו-Fragment מומרים אחרונים. יש להם הכי הרבה תלויות, הכי הרבה קוד legacy, ושגיאות שם הן היקרות ביותר.

טיפול באינטרופ בין Java ל-Kotlin

עד שהמעבר הושלם, מחלקות Java ו-Kotlin חיות זו לצד זו. Kotlin קורא ל-Java ללא בעיות. Java קורא ל-Kotlin — נדרשות annotations:

• @JvmStatic למתודות companion object שנדרשות מ-Java
• @JvmField לשדות ללא getters
• @JvmOverloads לפונקציות עם פרמטרי ברירת מחדל
• @Throws(IOException::class) אם פונקציית Kotlin זורקת exceptions מסומנות

התעלמות מה-annotations האלה היא סיבה נפוצה לכך שקוד שהומר אוטומטית לא מתקמפל מקבצי Java שכנים.

בדיקות במהלך המעבר

כל מחלקה שהומרה חייבת לעבור את הבדיקות הקיימות ללא שינוי — זה מבטיח שההמרה לא שברה את הלוגיקה. אם בדיקות חסרו, זה הרגע לכתוב אותן, לפני ההמרה, בזמן שהלוגיקה עדיין ברורה מקוד Java. אנחנו משתמשים ב-JUnit5 + MockK (למחלקות Kotlin) או Mockito (אם נדרשת תאימות לבדיקות Java).

CI חייב להריץ בדיקות על כל PR. מעבר בלי CI הוא כאוס: אי אפשר לעקוב איזה commit שבר את הלוגיקה.

class UserRepository(private val api: UserApi) {
    suspend fun getUser(id: Long): Result<User> = runCatching {
        api.getUser(id)
    }
}

מה עוד משתנה בדרך

במהלך המעבר, הגיוני לטפל בחוב טכני שנצבר: להחליף class UserRepository(private val api: UserApi) { suspend fun getUser(id: Long): Result<User> = runCatching { api.getUser(id) } } (שהוצא משימוש מאז API 30) ב-coroutines, לעבור מ-AsyncTask ל-SharedPreferences, לעדכן DataStore לגרסה עם פונקציות suspend של Kotlin במקום Retrofit.

אבל "בדרך" לא אומר "הכל בבת אחת". כל שינוי כזה מסכן רגרסיה. אנחנו מרכיבים רשימה מפורשת של "מה אנחנו עושים במסגרת המעבר"; כל השאר נכנס ל-backlog לספינטים הקרובים.

עדיפות מודולים למעבר

מה כלול בעבודת המעבר

• ביקורת בסיס קוד: הערכת נפח, כיסוי בדיקות, נקודות מורכבות
• תוכנית המרה בשלבים עם עדיפויות ולוחות זמנים
• כתיבת בדיקות למודולים קריטיים לפני ההמרה
• שיפור ארכיטקטוני ידני (coroutines, data classes, null safety)
• הכשרת הצוות בדפוסי Kotlin ו-API חדשים
• תמיכה לאחר המעבר: סקירת קוד, חידוד אינטרופ, אופטימיזציית ביצועים

לוחות זמנים

הם תלויים בגודל בסיס הקוד, כיסוי הבדיקות, והאם פיתוח תכונות מקביל מתנהל.

ההערכה מעודנת לאחר הביקורת. העלות מחושבת באופן אישי.

מעבר הוא השקעה. צוות שעובד על Kotlin עם coroutines ו-StateFlow סוגר משימות מהר יותר מאותו צוות על Java עם RxJava. לא כי Kotlin קסום יותר, אלא כי יש פחות boilerplate, כלי ניתוח טובים יותר (KSP לעומת KAPT, חוקי lint של Kotlin), ומערכת הספריות כבר לא מתנגדת. כתבו לנו לייעוץ מומחה והערכת פרויקט מקדימה.

אנחנו צוות עם 7 שנות ניסיון בפיתוח Android, שביצע למעלה מ-30 פרויקטי מעבר מ-Java ל-Kotlin. הזמינו ביקורת קוד ואנחנו נכין תוכנית מעבר מפורטת.