Analisi del codice dell'applicazione

È possibile eseguire il programma di analisi del codice per analizzare il codice e creare una versione strumentata del codice sorgente. Questa analisi è il primo passo per rifattorizzare le applicazioni monolitiche Java® in partizioni.

Programma di analisi del codice

Il programma di analisi del codice raccoglie i dati statici dal codice dell'applicazione delle tue applicazioni monolitiche Java utilizzate come input per il motore AI, che genera i suggerimenti della partizione. Questi dati statici sono richiesti anche come input per la strumentazione binaria, che raccoglie i dati di runtime dalle applicazioni distribuite. Quando il programma di analisi del codice esegue la scansione del codice Java , genera quattro file. I file JSON contengono metadati relativi alle classi scansionate e alla configurazione per lo instrumenter binario. I metadati includono informazioni quali i nomi delle classi, gli attributi dei membri immessi, i costruttori, i metodi con argomenti di input e tipi di ritorno e le ubicazioni dei file di origine delle classi.

Il programma di analisi del codice può anche strumentare il codice sorgente delle tue applicazioni monolitiche Java in modo che le tracce di runtime vengano raccolte quando queste applicazioni vengono eseguite. Il programma di analisi del codice esegue la scansione di tutte le classi Java di una applicazione per inserire le istruzioni di strumentazione nel formato System.err.println("Entering...") e System.err.println("Exiting...") in tutti i metodi di classe, inclusi i costruttori. Dopo il completamento della strumentazione del codice con l'analizzatore del codice, ricreare e ridistribuire l'applicazione monolitica Java .

La strumentazione del codice sorgente è una funzione obsoleta del programma di analisi del codice. La strumentazione binaria è l'opzione consigliata per la raccolta di tracce di runtime durante l'esecuzione di casi di utilizzo aziendali, eliminando la necessità di ricreare e ridistribuire l'applicazione monolitica Java .

Prerequisiti

Assicurarsi di soddisfare i requisiti di sistema .

Procedura

  1. Inserire il file di archivio binario dell'applicazione monolitica Java in una struttura di directory.

    I formati di file archivio Java validi includono .cba, .class, .ear, .eba, .jare .war. Inoltre, sono validi i file .rar e .zip che contengono i file binari di archivio Java .

  2. Eseguire il programma di analisi del codice rispetto al file binario dell'applicazione.

    Eseguire il comando analyze. Per ottenere la guida del comando, aggiungere l'opzione -h .

    mono2micro analyze -a <binary-file-path>

    Le seguenti informazioni spiegano la sintassi per il comando:

    • La variabile <binary-file-path> è il percorso per il file binario dell'applicazione da analizzare. Per default, il comando analyze crea una directory denominata binary-file-mono2micro sulla directory di lavoro dell'utente con diversi file JSON.

      È possibile aggiungere l'opzione -o per specificare il percorso della directory di output per i file JSON generati. L'utente che esegue il programma di analisi del codice deve avere accesso in lettura e scrittura alla directory /<output-dir-path>/ .

      mono2micro analyze -a <binary-file-path> -o <output-dir-path>
    • È possibile creare la configurazione per lo strumento binario che invia le tracce al flusso di output standard. Per impostazione predefinita, la strumentazione binaria utilizza il tuo codice Java con istruzioni System.err.println() per la generazione di tracce di runtime IBM Mono2Micro nel flusso di errore standard. L'impostazione dell'opzione --instrumentation-target sul valore out si applica anche alla strumentazione di origine se è stato utilizzato il comando mono2micro instrument .

Esempi per i flussi di errore standard e di output standard

Per il flusso di errore standard, eseguire il comando seguente:

mono2micro analyze -a /apps/daytrader-ee7.ear

Per il flusso di output standard, eseguire il comando seguente:

mono2micro analyze -a /apps/daytrader-ee7.ear --instrumentation-target out

Controllo dell'elenco di pacchetto Java per l'analisi binaria

Il programma di analisi binario esamina tutte le classi Java all'interno del file binario tranne i pacchetti esclusi per impostazione predefinita. È possibile controllare l'elenco predefinito di package esclusi con l'opzione -h .

Le opzioni seguenti vengono utilizzate esclusivamente per controllare i pacchetti Java da analizzare con il programma di analisi binario. Nessuna delle opzioni persiste perché il programma di analisi non salva alcun elenco o preferenza utente. Pertanto, è necessario specificare le opzioni desiderate per ogni esecuzione. Per le opzioni, specificare un elenco separato da virgole senza spazi vuoti, ad esempio:
com.test.app,org.xyz.lib,edu.abc
--add-to-exclude-packages
Aggiunge i pacchetti all'elenco predefinito di pacchetti da escludere. L'analisi binaria esclude i package di elenco predefiniti ed esclude anche l'elenco di package specificati da questa opzione.
--exclude-packages
Esclude l'elenco di pacchetti specificati da questa opzione dall'analisi binaria. Vengono analizzate tutte le classi tranne quelle in questi pacchetti specificati dall'utente, il che significa che l'elenco di pacchetti predefinito viene ignorato.
--include-packages
Analizza solo l'elenco di pacchetti specificato da questa opzione durante l'analisi binaria. Poiché solo le classi in questi package vengono analizzate, l'elenco di package predefinito viene ignorato.
--analyze-all
Forza l'analisi di tutte le classi e i package.

Risultati

Una volta completata correttamente l'analisi, se non viene specificata una directory di output, il programma di analisi del codice crea una directory denominata binary-file-mono2micro sulla directory di lavoro dell'utente con più file, dove binary-file è il nome del file binario Java analizzato. Ad esempio, se il file binario è daytrader-ee7.ear, il programma di analisi del codice crea una directory con il nome daytrader-ee7-mono2micro nella directory di lavoro dell'utente. Se viene specificata l'opzione di output, i file JSON vengono collocati nella directory fornita.

Dopo l'analisi, la directory contiene i seguenti file:

  • symTable.json
  • refTable.json
  • instrumenter-config.json
  • recommender-config.properties

I file symTable.json e refTable.json contengono metadati relativi alle classi sottoposte a scansione, ad esempio nomi, ubicazioni, nomi attributo, costruttori e metodi. Il file instrumenter-config.json fornisce la configurazione per lo instrumenter binario. Il file recommender-config.properties specifica l'ubicazione dell'archivio dell'applicazione Java su disco e i pacchetti esclusi o inclusi durante l'analisi.

Se la strumentazione di origine era abilitata sul programma di analisi del codice, la directory peer contiene anche una copia del codice di origine che è dotato di istruzioni System.err.println() che utilizzi in seguito per generare le tracce di runtime IBM Mono2Micro .

La strumentazione del programma di analisi del codice non stampa mai il valore delle variabili dell'applicazione. Lo scopo della strumentazione è quello di registrare i flussi temporali attraverso i diversi metodi e costruttori delle classi, e non i valori delle variabili durante il runtime.

Limitazioni correnti

  • Quando si compila il codice fornito dal programma di analisi del codice, è possibile cheunreachable codeerrore di compilazione. In alcuni casi limite, la strumentazione del programma di analisi del codice potrebbe inserire istruzioni di strumentazione, che il compilatore Java rileva come non raggiungibili.

    Per superare il problema, rimuovere o impostare come commento queste istruzioni non raggiungibili. La loro rimozione non incide in alcun modo sulla generazione delle tracce di runtime.

  • Quando si esegue il programma di analisi del codice, potrebbe verificarsi un errore di memoria insufficiente dal processo Java . Per risolvere il problema, impostare la variabile di ambiente --java-opts specificando una dimensione heap massima elevata come valore.

    Ad esempio, per specificare una dimensione heap Java massima di 512 megabyte, eseguire uno dei comandi riportati di seguito.

    mono2micro analyze -s <src-dir-path>  --java-opts "-Xmx512m"
    mono2micro instrument -s <src-dir-path>  --java-opts "-Xmx512m"
  • Quando il programma di analisi binario trova più di una classe Java con lo stesso nome e lo stesso nome pacchetto, analizza il primo identificato e ignora gli altri con lo stesso nome e lo stesso nome pacchetto. I nomi duplicati possono verificarsi se la stessa classe è contenuta in più file binari all'interno dell'archivio binario. In questo caso, viene registrato un avviso per segnalare i duplicati trovati. Nella maggior parte dei casi, questo non è un problema, soprattutto se le classi trovate sono identiche. Tuttavia, può essere un problema se le classi trovate presentano differenze nella struttura.

Operazioni successive

Se si desidera ottenere i suggerimenti di partizionamento in base alla logica aziendale nell'applicazione, eseguire le applicazioni monolitiche Java con la strumentazione per generare i file di traccia di runtime. Se invece volete ottenere più rapidamente raccomandazioni basate esclusivamente sull'analisi statica della vostra applicazione, controllate i dati raccolti e poi eseguite il motore AI. Le informazioni provenienti dall'analizzatore di codice e, opzionalmente, dallo strumento binario e dal registratore di casi d'uso, vengono utilizzate come input per il motore di intelligenza artificiale, che genera raccomandazioni sulle partizioni. È importante mantenere il file di archivio dell'applicazione Java nella stessa ubicazione sul disco in modo che il motore AI possa analizzarlo ulteriormente durante la fase di suggerimento della partizione.

Se si è scelto di raccogliere i file di traccia di runtime tramite la strumentazione di origine, dopo che il programma di analisi del codice ha completato correttamente il processo di strumentazione, è possibile creare e distribuire l'applicazione strumentata in ambienti non di produzione ma rappresentativi. Seguire esattamente il processo utilizzato per creare e distribuire l'applicazione originale. A seconda degli ambienti, le applicazioni e le relative versioni strumentate possono essere su macchine bare metal, macchine virtuali o contenitori.