המניע מאחורי J2ObjC
J2ObjC החלה מתסכול. התסכול שצוותי פיתוח ניסו לנסות לבצע במהירות חזרה על מוצרי האינטרנט והנייד שלהם מבלי שהפעולה שלהם תיפגע. רבים ממוצרי הלקוח של Google נוצרו באמצעות GWT לאפליקציות אינטרנט (שנקראת עכשיו J2CL), ו-Android API למכשירים ניידים עם Android. פעולה זו עזבה את אפליקציות iPod/iPad, שאמורות להיות אפליקציות אינטרנט של JavaScript או כתובות בכתב יד ב-Objective-C. למרות ש-GWT ואפליקציות ל-Android היו יכולות לחלוק קוד לוגיקה עסקית (לא ממשק משתמש), לא היה פתרון לשיתוף הקוד עם אפליקציות ל-iOS.
חקרו כמה גישות לפתרון בעיה זו. XMLVM נראה מבטיח מאוד, אבל בזמנו, הדף מתרגם iOS ציין שהפרויקט הושעה (הוא פעיל עכשיו שוב, והוא חלופה טובה לפרויקט הזה). כלי תרגום אחרים ביצעו המרה חד-פעמית של קוד, ונדרשת עריכה נוספת לפני שהפלט שלהם נוצר בהצלחה ופועל.
פרויקט חדש נוצר
כבר בהתחלה, מהנדסים רבים חשבו שמתרגם כמו J2ObjC לא אפשרי. יצירת כלי שיכול לתרגם באופן מדויק את כל קודי האפליקציות של Java ל-iOS, אבל באמת בלתי אפשרי לשמור על הסמנטיקה שלו בצורה מושלמת! הסיבה לכך היא שב-iOS יש סטנדרטים מחמירים לעיצוב ממשק משתמש, והמשתמשים מודעים לכך שאפליקציות לא פועלות בהתאם. לדעתנו, הדרך היחידה לקבל ממשק משתמש מהיר ומהיר ב-iOS היא לכתוב אותו ב-Objective-C באמצעות ה-frameworks של iOS SDK של Apple.
מכיוון שרוב המהנדסים למדו ממגבלות בחשבון דיפרנציאלי, כדאי מאוד להתקרב למה הבלתי אפשרי. לכן הגדרנו מגבלות שישפרו את הסיכויים לכך ש-J2ObjC יצליח:
- תמיכה בפיתוח בצד הלקוח בלבד. אפשר לתרגם את כלי שורת הפקודה ואת קוד השרת, אבל סביר להניח שבתרחיש לדוגמה הזה יהיו בעיות שלא מטופלות על ידי J2ObjC.
- תומכים רק בקוד היגיון עסקי, ומרוחקים מאוד מממשקי ה-API של ממשק המשתמש (כמו שהמפות הישנות נהגו לעשות בפינות המרוחקות שלהן, 'כאן יש מפלצות').
- נדרש את ה-iOS Foundation ולא בסיס כללי יותר.
- אחרי שמיישמים את השיטות המומלצות של Apple לניהול זיכרון, השתמשו ב-Xcode's Instruments כדי לוודא שרמת הביצועים והשימוש בזיכרון תקינים.
- חשוב להתמקד רק במה שנחוץ למפתחי האפליקציות, ולא במה שדרוש למען שלמות האפליקציה. צורכי האפליקציות האמיתיים מניעים אותם.
אנחנו יועילו לכם, אולי גם אתם
התחלנו להשתמש ב-J2ObjC בקוד פתוח, כי חלק מהפרויקטים הפנימיים מצאו שהשיטה הזו פותרת את הבעיה של שיתוף הלוגיקה העסקית של Java עם האפליקציות שלהם ל-iOS. חלק מהצוותים מסתמכים כרגע על המתרגם, ואנחנו מוסיפים פונקציונליות חדשה ומתקנים באגים רבים. אנחנו מזמינים צוותים אחרים של אפליקציות לנייד לנסות את האפליקציה, ואומרים לנו מה עובד ומה טעון שיפור.
מבחינתנו, העבודה על הפרויקט מתגמלת מאוד. שתי המשימות הקשות ביותר של כל מתרגם Java הן 1) ניתוח נכון, בדיקת סוג המקור ופתרון שלו, 2) יצירה של סביבת זמן ריצה תואמת ל-Java. הידור של Javac מטפל במשימה הראשונה כמו שצריך, וסביבת זמן הריצה (כולל בדיקות היחידה של האתר) מבוססת על ספריית libcore ב-Android. זה משאיר לנו את הכיף: שינוי של עצי תחביר מופשטים ויצירת פלט מקור שבדרך כלל קל לניפוי באגים. אם אתם מתעניינים בכלי או מהדרים של Java, הצטרפו אלינו! יש עדיין הרבה מה לעשות, ונשמח לעזור.