انگیزه پشت J2ObjC

J2ObjC از سرخوردگی شروع کرد. ناامیدی چندین تیم توسعه از تلاش برای تکرار سریع محصولات وب و موبایل خود بدون اینکه آنها از نظر عملکرد از هم جدا شوند. بسیاری از محصولات مشتری Google با استفاده از GWT برای برنامه‌های وب (اکنون J2CL ) و Android API برای دستگاه‌های تلفن همراه Android ایجاد شده‌اند. این برنامه‌های آی‌پاد/آی‌پد را باقی گذاشت، که باید یا برنامه‌های وب جاوا اسکریپت باشند یا با Objective-C دست‌نویس شوند. اگرچه برنامه‌های GWT و Android می‌توانند کد منطق تجاری (غیر UI) را به اشتراک بگذارند، هیچ راه‌حلی برای اشتراک‌گذاری آن کد با برنامه‌های iOS وجود نداشت.

چندین رویکرد برای حل این مشکل بررسی شد. XMLVM بسیار امیدوارکننده به نظر می رسید، اما در آن زمان صفحه مترجم iOS آن اعلام کرد که پروژه به حالت تعلیق درآمده است (اکنون دوباره فعال است و جایگزین خوبی برای این پروژه است). سایر ابزارهای ترجمه تبدیل کد یکباره را انجام دادند و قبل از اینکه خروجی آنها با موفقیت ساخته و اجرا شود نیاز به ویرایش بیشتری داشتند.

یک پروژه جدید متولد شد

از همان ابتدا، بسیاری از مهندسان فکر می کردند مترجمی مانند J2ObjC امکان پذیر نیست. ایجاد ابزاری که بتواند با دقت تمام کدهای برنامه جاوا را به iOS ترجمه کند و در عین حال معنای آن را کاملاً حفظ کند، در واقع غیرممکن است! دلیلش این است که iOS استانداردهای طراحی رابط کاربری دقیقی دارد و کاربران آن زمانی که یک اپلیکیشن به آنها پایبند نیست، بسیار آگاه هستند. به نظر ما، تنها راه برای به دست آوردن یک رابط کاربری سریع iOS در سطح جهانی، نوشتن آن در Objective-C با استفاده از چارچوب‌های iOS SDK اپل است.

همانطور که اکثر مهندسان از محدودیت ها در حساب دیفرانسیل یاد گرفتند، با این حال، نزدیک شدن به غیرممکن می تواند بسیار مفید باشد. بنابراین ما مجموعه ای از محدودیت ها را تعیین کردیم که شانس موفقیت J2ObjC را افزایش می دهد:

• فقط از توسعه سمت مشتری پشتیبانی کنید. ابزارهای خط فرمان و کد سرور در تئوری می توانند ترجمه شوند، اما این مورد استفاده احتمالاً مشکلاتی دارد که توسط J2ObjC برطرف نشده است.
• فقط از کد منطقی کسب و کار پشتیبانی کنید و از APIهای رابط کاربری بسیار دور بمانید (همانطور که نقشه‌های قدیمی در گوشه‌های بیرونی خود داشتند، "اینجا هیولاهایی وجود دارند").
• به چارچوب بنیاد iOS نیاز دارید، نه یک پایه عمومی تر.
• پس از اجرای بهترین شیوه های اپل برای مدیریت حافظه، از ابزارهای Xcode برای تأیید عملکرد قابل قبول و استفاده از حافظه استفاده کنید.
• فقط بر روی آنچه توسعه دهندگان برنامه نیاز دارند تمرکز کنید، نه آنچه برای کامل بودن مورد نیاز است. نیازهای برنامه های کاربردی واقعی نیازمندی های پروژه را هدایت می کند.

ما آن را مفید می دانیم، شاید شما نیز مفید باشید

ما J2ObjC را منبع باز کردیم، زیرا برخی از پروژه های داخلی متوجه شدند که مشکل به اشتراک گذاری منطق تجاری جاوا با برنامه های iOS آنها را حل می کند. اکنون چندین تیم به مترجم متکی هستند و ما مشغول اضافه کردن عملکردهای جدید و رفع بسیاری از اشکالات هستیم. ما از سایر تیم‌های برنامه تلفن همراه استقبال می‌کنیم تا آن را امتحان کنند و به ما اطلاع دهند که چه چیزی کار می‌کند و چه چیزی نیاز به بهبود دارد.

ما همچنین کار بر روی پروژه را پاداش می دانیم. دو کار سخت برای هر مترجم جاوا عبارتند از: 1) تجزیه صحیح، بررسی تایپ و حل منبع جاوا، و 2) ارائه یک محیط زمان اجرا جاوا سازگار. اولین کار توسط کامپایلر javac به خوبی انجام می شود و محیط زمان اجرا (شامل تست های واحد آن) بر اساس کتابخانه libcore Android است. این چیزهای سرگرم کننده را برای ما باقی می گذارد: جهش درختان نحو انتزاعی و تولید خروجی منبع به طور کلی برای اشکال زدایی آسان. اگر به ابزارها یا کامپایلرهای جاوا علاقه دارید، به ما بپیوندید! هنوز کارهای زیادی برای انجام دادن وجود دارد و ما دوست داریم کمک کنیم.