Alternative alla strumentazione bytecode Java

Question

Sto avviando un progetto che dovrà utilizzare le applicazioni Java per scopi di copertura (definizione-utilizzo di variabili, ecc.). Deve aggiungere istruzioni di tracciamento e qualche logica all'applicazione e forse rimuovere istruzioni.

Ho cercato modi di strumento codice Java e quello che trovo sempre riguarda la strumentazione bytecode.

La mia domanda è: è l'unico modo per strumentare le applicazioni Java? C'è un altro modo per farlo? Quali sono i vantaggi della strumentazione bytecode rispetto alle altre?

Probabilmente userò la soluzione bytecode, ma voglio sapere quali sono i problemi con gli altri approcci (se ce ne sono) per decidere con precisione.

Grazie!

Answer 1

L'altro metodo vicino alla modifica del codice byte utilizza AOP (Aspect Oriented Programming). La libreria principale è AspectJ che inoltre definisce principalmente l'area.

La terza opzione che potrebbe essere interessante (dal momento che si sta appena iniziando con il programma) utilizza Spring. Significa che dovrai imparare un po 'di IOC (inversione del controllo) ma fondamentalmente significa che invece di creare i tuoi oggetti tu stesso lasci che la molla lo faccia per te, e ha vantaggi perché quando la primavera è carica della creazione puoi aggiungere ogni sorta di cose nel processo di creazione senza che tu debba davvero dichiararlo tutto in aspectj.

in termini di complessità avrei probabilmente darei:

• molla (più semplice)
• aspectj
• bytecode strumentazione (più difficile)

ma è esattamente il contrario, quando parlando di capacità (potere). per esempio fare qualcosa come il codice di sottrazione è possibile solo usando l'ultimo (credo)

Answer 2

Si dovrebbe verificare AspectJ

Da ciò che si descrive si sarà in grado di fare quello che vuoi con esso.

Fare da soli la strumentazione bytecode è assolutamente possibile ma è molto più complicato.

Penso che dovresti prima controllare AsepctJ e tornare a fare da solo la strumentazione bytecode come ultima risorsa.

Answer 3

Vedere il mio paper on building coverage tools using program transformation engines. Questo approccio ha il vantaggio che può essere utilizzato su linguaggi di programmazione arbitrari. Inoltre, vede il codice sorgente nel modo in cui il programmatore lo vede, non come codici byte compilati (dato che i generici diventano più complessi e ottengono basi in codici byte più fini, diventa più difficile capire il codice sorgente controllando il codice byte).

Vale la pena notare che la trasformazione del programma generalizza la programmazione orientata all'aspetto.