2013-02-01 7 views
6

Sto usando javac da tools.jar (ad esempio JavaCompiler) per analizzare i file java. Analizzo le fonti utilizzando l'implementazione di TreePathScanner. Finora tutto sembra a posto, dato che posso analizzare importazioni, nome pacchetto, nome classe, nome metodo, istruzioni ...Come leggere i commenti in linea dal file java usando javac tools parser?

Ma ho problemi con inline commenti - Non posso semplicemente farli apparire nel creato l'albero AST, o visitato loro. Tuttavia, sono in grado di leggere javadoc commenti per classi, metodi ecc., Ma senza commenti in linea.

Come leggere i commenti in linea nel modo migliore? Sto guardando il codice sorgente di netbeans (dato che sta usando javac anche per l'analisi), ma non riesco a trovare facilmente nulla a riguardo.

La mia soluzione disperata userebbe la posizione delle istruzioni del file sorgente e quindi analizzerò manualmente per commentare tutto ciò che è tra due istruzioni. O cosa simile, ma tra due nodi dell'albero.

Qualcuno sa una soluzione migliore? Grazie!

+0

Vedo che com.sun.tools.javac.main.JavaCompiler ha un flag keepComments impostato su false per impostazione predefinita. E 'quello che stai cercando di usare? Hai provato a cambiarlo? – jdb

+0

sì, avevo già impostato questo valore, non ho notato alcuna differenza. – igr

risposta

4

Non è possibile. Il compilatore li getta via. I compilatori lo fanno sempre. Il compilatore Java non butta via i commenti Javadoc solo perché Javadoc usa il compilatore per trovarli e i ragazzi Javadoc si sono uniti ai ragazzi del compilatore.

+0

Questo è vero. Ho controllato il sorgente di javac e nella classe 'Scanner' è possibile vedere il seguente metodo:' protected void processComment (Stile CommentStyle) 'che registra solo il messaggio di debug. Proverò a vedere se riesco a scavalcarlo. – igr

+0

Sono riuscito a eseguire parser non usando ** JavaCompiler **, ma solo classi ** Scanner ** e ** Parser **; ed è stato in grado di sovrascrivere il metodo 'processComment', ma ...questo metodo fornisce solo le informazioni che il commento è stato elaborato e il tipo di commenti e nient'altro (come valore, posizione ecc.). – igr

+0

btw, sembra che il compilatore di eclissi AST conservi i commenti. – igr

1

Una differenza chiave tra un "parser del compilatore" e un "parser di riprogettazione" ha a che fare con quali informazioni vengono acquisite sul layout, i commenti e i formati di valori letterali. Come altri hanno osservato, molti compilatori buttano via tutte queste informazioni, in quanto non è pertinente compilare il codice a basso livello.

Analogamente, i generatori di parser classici (come JavaCC, ANTLR, ecc.) Offrono molto poco supporto per capturring/rigenerare queste informazioni.

I parser di reingegnerizzazione, al contrario, vengono utilizzati per analizzare i codici e commenti, a volte anche per rivedere il codice senza perdere (o correggere i commenti in modo appropriato). Per l'analisi del codice con commenti, non è possibile eliminare i commenti: -} Per la modifica del codice, se si rigenera il codice modificato in base all'originale, è utile se il codice modificato conserva layout di codice, commenti e "formati" letterali (ad es. , la registrazione di un valore letterale esadecimale come valore decimale è legale e equivalente, ma rende gli autori originali piuttosto infelici). Per fare ciò, i parser di reingegnerizzazione hanno bisogno di lessici speciali per catturare tutti questi dati e per analizzare i macchinari che non li buttano via.

Il nostro DMS Software Reengineering Toolkit include, beh, un parser di reengineering come macchina generica; I parser basati su DMS esistono per un'ampia varietà di linguaggi (incluso l'interesse di OP in Java). DMS acquisisce tutti i commenti/layout/informazioni di formattazione. Gli strumenti di analisi hanno accesso a tutto questo.

TXL e Stratego forniscono anche supporto per questo.