AspectJ 1.7 & invokedynamic

E' stato appena rilasciato AspectJ 1.7 che allinea il compilatore (weaver) alla versione 3.7 di Eclipse e presto raggiungerà la versione di Juno (4.x). E' interessante notare che il numero di versione, .7, corrisponde alla major release di Java, la 7 appunto, che il nuovo compilatore supporta. In particolare si sta lavorando molto per supportare la nuova istruzione invokedynamic di Java 7, anche se ancora non ci sono dei join points definiti.

Questa istruzione permette a Java di invocare un metodo su un tipo di oggetto non specificato, aprendo quindi la strada all'integrazione con i linguaggi di scripting. Infatti Kava è sempre stato un linguaggio staticamente tipizzato, e tutte le versione di invokeXXX (come invokevirtual) hanno sempre compreso un tipo sul quale chiamare il metodo oltre alle informazioni dei tipi parametrici e di ritorno. Con la nuova istruzione invece i tipi non sono presenti, di fatto si usa un trucco simile ai puntatori void* di C: nel constant pool si inserisce un MethodHandle che viene linkato alla prima invocazione, lasciando così il bytecode "libero" da tipizzazioni preventive.

Call vs Execution Join Point

Si sente spesso parlare di differenza fra i join point di call e di execution, tanto che la domanda è molto spesso fatta da chi è alle prime armi con l'AOP e AspectJ. Per chiarezza occorre ricordare che mentre un call "osserva" il codice dal lato chiamante (quindi un this punta all'oggetto che invoca un metodo), un execution "osserva" il codice dal lato chiamato (quindi un this punta all'oggetto sul quale il metodo è invocato). Tuttavia esiste un'ulteriore differenza, sottile e subdola e che potrebbe lasciare sconcertati quando si utilizza la reflection: un execution join point, dovendo essere sul lato del codice chiamato, viene sempre messo inline con il codice stesso. Questo significa che anche se la chiamata al metodo avviene tramite reflection il join-point verrà processato. Diverso il caso invece per call, che non può essere messo inline (si avrebbe un contesto differente) e che quindi viene normalmente bypassato dall'uso della reflection. In altre parole, se si vuole gestire un join point di tipo call occorre prevedere tutte le chiamate dirette al metodo e anche quelle che eventualmente vengono fatte tramite reflection.

Importare un progetto SVN in Eclipse gestendolo con Git

Al fine di meglio apprendere Git, il sistema di gestione dei sorgenti appositamente sviluppato per il Kernel di Linux (ma usato anche in altri progetti), ho deciso di convertire un progetto Java che gestisco con un repository SVN in un repository Git.
Su questo progetto lavoro pressocché da solo, usando Eclipse e i tools SVN sviluppati dal gruppo di SVN stesso, quindi non dovrei molti problemi nella migrazione. Per sicurezza ho deciso di mantenere per alcuni giorni entrambi i progetti in Eclipse, così da poter tornare abbastanza semplicemente al sistema SVN in caso di problemi.
Di seguito i passi necessari all'installazione di EGit, il plug-in per Eclipse/Git e per l'importazione del progetto.

Installazione del plug-in per Eclipse: EGit
L'installazione del plugin non è un'operazione banale, poiché occorre importare i vari sotto progetti in Eclipse e compilarli a mano. In particolare occorre seguire i passi:

• scaricare i progetti di EGit in una directory temporanea con il comando git clone git://repo.or.cz/egit.git
  

• importare i progetti in Eclipse. Per fare questo selezionare da Eclipse il menù File->Import->existing projects into workspace e verificare che i progetti compaiano nel project explorer.

• ora occorre compilare i progetti, per fare questo occorre darre il classi Build-All dal menù Project. Questo passo è opzionale se avete abilitato il build automatico dei progetti.
• occorre ora esportare un plug-in compatibile per Eclipse, quindi dal menù File->Export si seleziona la voce Plug-in and fragments. E' necessario impostare come percorso la root dell'installazione corrente di Eclipse.
  

• a questo punto è possibile riavviare Eclipse, cancellare la directory temporanea dove si sono scaricati i sorgenti di EGit, rimuovere i progetti dal project manager e verificare che il plugin sia installato. In particolare per questo è sufficiente controllare che nell'import ci sia una voce Git.

Conversione di un progetto SVN in repository Git
Nel mio caso il progetto SVN si chiama HRPM e risiede su una macchina remota. Dopo aver installato sulla mia macchina tutti i tool git, fra i quali git-svn, posso importare il progetto SVN in un repository locale git con la seguente procedura:

• creare una directory dove inserire il repository, entrare nella directory e inizializzare il repository git: git-svn init svn+ssh://host/sviluppo/svn//hrpm
• importare i sorgenti con il comando git-svn fetch -r900 (dove 900 rappresenta il numero di revisione a cui il repository SVN è arrivato)
• dopo qualche secondo (o qualche minuto), il repository git sarà pronto al suo utilizzo. E' ora possibile usare questo repository o importarlo in Eclipse.
• (opzionale) siccome il progetto importato nel repository contiene lo stesso nome del suo fratello su SVN, qualora si vogliano mantenere entrambi i progetti è necessario editare il file .project che si trova nella directory dei sorgenti cambiandone il nome, come ad esempio in HRPM-git.
  

Importare il progetto in Eclipse
Avendo ora il progetto su un repository Git è possibile importare il progetto all'interno di Eclipse:

• dal menù File->Import->Git selezionare la voce Git-Repository;
• selezionare nella dialog che si apre la voce file e specificare il percorso dove risiede il repository git;
  

• la dialog successiva chiede quale branch si vuole importare. Siccome il repository è appena stato creato, il branch master è quello selezionato per default.
  

• a questo punto il progetto è importato, ma non ancora visibile in Eclipse: esiste la cartella corrispondente nel workspace, ma non il progetto nel project explorer. Per far comparire il progetto, è necessario procedere ad una successiva importazione di un progetto esistente: File->Import->Existing Project into Workspace come mostrato di seguito

• si specifica la directory che contiene il progetto (ATTENZIONE: questa volta si deve specificare la directory all'interno del workspace) e si vedrà comparire il progetto fra quelli selezionabili. Qualora esista già un progetto con lo stesso nome Eclipse non mostrerà nessun progetto selezionabile.

• e il progetto verrà visualizzato nel project explorer. Non è ancora finita, perché il progetto è locale, e non verrà gestito da Git. Occorre quindi fare click destro sul progetto, selezionare Team->Share Project e usare Git come metodo di condivisione.

• da ultimo si informa Eclipse di usare un repository esistente, e il gioco è fatto.

La cosa interessante è che il procedimento ha funzionato perfettamente nonostante il mio progetto fosse non un semplice progetto Java, bensì un progetto AspectJ. L'unica pecca del plug-in, almeno ad una prima vista, è l'utilizzo dei caratteri in stile CVS per indicare che il contenuto necessita di commit/aggiornamenti, mentre l'uso delle icone del plug-in SVN è sicuramente più gradevole.

Link utili:
Eclipse Git Plugin Installation
A dummy guide to use Egit

Compilazione incrementale Ant usando AspectJ in Eclipse

Dopo aver aggiornato i tools di sviluppo di AspectJ per Ecplise (AJDT) alla versione 1.6.1, mi sono trovato una brutta sorpresa nella compilazione tramite Ant (task iajc): la compilazione incrementale non funziona più se non si specifica un parametro sourceRoots che è praticamente equivalente al precedente parametro che indica la directory che contiene i sorgenti. Ma ahimé nemmeno così la compilazione incrementale può funzionare, e infatti si ottiene la schermata di Eclipse che segue:


Il fatto è che Ant non può sapere quali file sono stati modificati, e quindi quali sorgenti debbano essere applicati dal weaver, percui di fatto ant rimane in attesa come processo attendendo di ricompilare nuovamente il set dei sorgenti. Quindi il task iacj diventa una sorta di processo che non termina mai e che addende sempre input dall'utente per ricompilare. Non esiste quindi nessuna soluzione apparente per usare ant in incremental mode all'interno di Eclipse, percui ci si deve rivolgere al compilare degli AJDT per avere una compilazione incrementale.