La motivazione alla base di J2ObjC

J2ObjC è nato dalla frustrazione, dalla frustrazione di diversi team di sviluppo per provare a eseguire rapidamente l'iterazione dei propri prodotti web e mobile senza perdere le proprie funzionalità. Molti dei prodotti client di Google sono stati creati utilizzando GWT per le app web (ora J2CL) e l'API Android per dispositivi mobili Android. Ciò lasciava le app per iPod/iPad, che dovevano essere app web JavaScript o scritte a mano in Objective-C. Anche se le app per Android e GWT potevano condividere il codice della logica di business (non UI), non esisteva alcuna soluzione per la condivisione di quel codice con le app per iOS.

Sono stati studiati diversi approcci per risolvere questo problema. XMLVM sembrava molto promettente, ma all'epoca la pagina del traduttore per iOS affermava che il progetto era stato sospeso (ora è di nuovo attivo ed è una buona alternativa a questo progetto). Altri strumenti di traduzione eseguivano la conversione del codice una tantum, richiedendo modifiche aggiuntive prima di poter creare ed eseguire l'output.

È nato un nuovo progetto

Fin dall'inizio, molti ingegneri pensavano che non fosse possibile usare un traduttore come J2ObjC. È davvero impossibile creare uno strumento in grado di tradurre con precisione tutto il codice delle applicazioni Java in iOS mantenendo perfettamente la sua semantica. Questo perché iOS ha rigorosi standard di progettazione dell'interfaccia utente e i suoi utenti sono molto consapevoli del fatto che un'app non li rispetta. A nostro avviso, l'unico modo per ottenere un'interfaccia utente iOS veloce e di altissimo livello è scriverla in Objective-C utilizzando i framework dell'SDK per iOS di Apple.

Tuttavia, la maggior parte degli ingegneri ha imparato dai limiti nel calcolo differenziale, ma può essere molto utile avvicinarsi all'impossibile. Pertanto, abbiamo definito una serie di limiti che avrebbero aumentato le probabilità di successo di J2ObjC:

• Supporta solo lo sviluppo lato client. In teoria, gli strumenti a riga di comando e il codice server potrebbero essere tradotti, ma è probabile che questo caso d'uso presenti problemi non risolti da J2ObjC.
• Supportano solo il codice della logica di business e rimani lontani dalle API dell'interfaccia utente (come un tempo le vecchie mappe avevano negli angoli più esterni, "qui ci sono mostri").
• Richiedono l'iOS Foundation Framework, non una base più generale.
• Utilizza Xcode's strumenti per verificare prestazioni e utilizzo della memoria accettabili, dopo aver implementato le best practice di Apple per la gestione della memoria.
• Concentrati solo su ciò che è necessario per gli sviluppatori delle applicazioni, piuttosto che su ciò che è necessario per completezza. Le esigenze delle applicazioni reali determinano i requisiti dei progetti.

Per noi è utile, magari anche tu

Abbiamo reso open source J2ObjC perché alcuni progetti interni stavano scoprendo che risolvesse il problema della condivisione della logica di business Java con le loro app per iOS. Molti team si affidano al traduttore e stiamo aggiungendo nuove funzionalità e correggendo molti bug. Invitiamo altri team di app mobile a provare questa funzionalità e a farci sapere cosa funziona e cosa deve migliorare.

Inoltre, riteniamo gratificante di lavorare al progetto. Le due attività più difficili per qualsiasi traduttore Java sono 1) l'analisi corretta, il controllo del tipo e la risoluzione dell'origine Java e 2) fornire un ambiente di runtime Java conforme. La prima attività viene gestita correttamente dal compilatore javac e l'ambiente di runtime (inclusi i relativi test delle unità) si basa sulla libreria libcore di Android. Ci rimane un'altra cosa divertente: mutare gli alberi della sintassi astratta e generare un output di origine generalmente facile da sottoporre a debug. Se ti interessano gli strumenti o i compilatori Java, unisciti a noi. C'è ancora molto da fare e ci piacerebbe aiutarti.