Động lực của J2ObjC

J2ObjC bắt đầu thất vọng; sự thất vọng mà một số nhóm phát triển đã cố gắng nhanh chóng lặp lại các sản phẩm web và thiết bị di động của họ mà không có sự khác biệt về chức năng. Nhiều sản phẩm ứng dụng của Google được tạo bằng GWT cho các ứng dụng web (hiện là J2CL) và API Android cho thiết bị di động Android. Điều đó khiến các ứng dụng iPod/iPad phải là ứng dụng web JavaScript hoặc được viết tay trong Objective-C. Mặc dù các ứng dụng GWT và Android có thể chia sẻ mã logic kinh doanh (không phải giao diện người dùng), nhưng không có giải pháp nào để chia sẻ mã đó với các ứng dụng iOS.

Chúng tôi đã nghiên cứu một số phương pháp để giải quyết vấn đề này. XMLVM có vẻ rất hứa hẹn, nhưng tại thời điểm đó trang trình biên dịch iOS của trang cho biết rằng dự án đã bị tạm ngưng (hiện đã hoạt động trở lại và là một giải pháp thay thế hiệu quả cho dự án này). Các công cụ dịch khác đã chuyển đổi mã một lần, yêu cầu chỉnh sửa thêm trước khi các công cụ dịch đó tạo và chạy thành công.

Một dự án mới ra đời

Ngay từ đầu, nhiều kỹ sư đã nghĩ rằng không thể có một dịch giả như J2ObjC. Thật sự không thể tạo được một công cụ có thể dịch chính xác tất cả mã ứng dụng Java sang iOS mà vẫn giữ nguyên ngữ nghĩa một cách hoàn hảo! Đó là do iOS có các tiêu chuẩn nghiêm ngặt về thiết kế giao diện người dùng và người dùng sẽ biết rất rõ khi nào ứng dụng không tuân thủ các tiêu chuẩn đó. Theo chúng tôi, cách duy nhất để có được giao diện người dùng iOS nhanh và đẳng cấp thế giới là viết giao diện đó trong Objective-C bằng khung SDK iOS của Apple.

Tuy nhiên, vì hầu hết các kỹ sư đã học được từ các giới hạn trong phép tính vi phân, việc tiến gần đến những điều không thể thực hiện có thể rất hữu ích. Do đó, chúng tôi đã đặt ra một tập hợp các giới hạn giúp cải thiện cơ hội thành công cho J2ObjC:

• Chỉ hỗ trợ phát triển phía máy khách. Các công cụ dòng lệnh và mã máy chủ trong lý thuyết có thể được dịch, nhưng trường hợp sử dụng đó có thể có các vấn đề chưa được J2ObjC giải quyết.
• Chỉ hỗ trợ mã logic nghiệp vụ và tránh xa các API giao diện người dùng (như bản đồ cũ thường có trong các góc xa của chúng, "ở đây có quái vật").
• Yêu cầu Khung nền tảng iOS, không phải là cơ sở chung chung hơn.
• Hãy sử dụng Công cụ của Apple để xác minh mức sử dụng bộ nhớ và hiệu suất chấp nhận được, sau khi triển khai các phương pháp hay nhất của Apple để quản lý bộ nhớ.
• Chỉ tập trung vào những gì mà nhà phát triển ứng dụng cần, thay vì những gì cần thiết cho tính hoàn chỉnh. Ứng dụng thực cần các yêu cầu thúc đẩy dự án.

Chúng tôi thấy việc này hữu ích và có thể bạn cũng sẽ thích

Chúng tôi cung cấp nguồn mở J2ObjC vì một số dự án nội bộ đã giải quyết được vấn đề trong việc chia sẻ logic kinh doanh Java với các ứng dụng iOS của họ. Hiện tại, một số nhóm đã dựa vào trình biên dịch, và chúng tôi đang tích cực bổ sung chức năng mới cũng như sửa nhiều lỗi. Chúng tôi hoan nghênh các nhóm phát triển ứng dụng di động khác dùng thử và cho chúng tôi biết những điều hiệu quả và những gì cần cải thiện.

Chúng tôi cũng tìm thấy những thành quả xứng đáng khi hoàn thành dự án. 2 tác vụ khó nhất đối với mọi trình dịch Java là 1) phân tích cú pháp, kiểm tra loại và phân giải nguồn Java chính xác, và 2) cung cấp một môi trường thời gian chạy Java tuân thủ chính xác. Tác vụ đầu tiên được trình biên dịch javac xử lý tốt và môi trường thời gian chạy (bao gồm cả các hoạt động kiểm thử đơn vị) dựa trên thư viện Android libcore. Điều đó sẽ mang lại cho chúng ta một công việc thú vị: thay đổi cây cú pháp trừu tượng và tạo đầu ra nguồn thường dễ gỡ lỗi. Nếu bạn quan tâm đến các công cụ hoặc trình biên dịch Java, hãy tham gia cùng chúng tôi! Vẫn còn rất nhiều việc phải làm và chúng tôi rất mong được giúp bạn.