Analyse du code d'application

Vous pouvez exécuter l'analyseur de code pour analyser votre code et créer une version instrumentée de votre code source. Cette analyse est la première étape de la refonte de vos applications monolithiques Java® en partitions.

Analyseur de code

L'analyseur de code collecte des données statiques à partir du code d'application de vos applications monolithiques Java qui est utilisé comme entrée dans le moteur d'intelligence artificielle, qui génère des recommandations de partition. Ces données statiques sont également requises en tant qu'entrée pour l' instrumenter binaire, qui collecte les données d'exécution à partir de vos applications déployées. Lorsque l'analyseur de code analyse le code Java , il génère quatre fichiers. Les fichiers JSON contiennent des métadonnées relatives aux classes et à la configuration analysées de l'instrumentation binaire. Les métadonnées incluent des informations telles que les noms de classe, leurs attributs de membre typés, les constructeurs, les méthodes avec les arguments d'entrée et les types de retour, ainsi que l'emplacement des fichiers source des classes.

L'analyseur de code peut également instrumenter le code source de vos applications monolithiques Java afin que les traces d'exécution soient collectées lors de l'exécution de ces applications. L'analyseur de code analyse toutes les classes Java d'une application pour insérer des instructions d'instrumentation sous la forme System.err.println("Entering...") et System.err.println("Exiting...") dans toutes les méthodes de classe, y compris les constructeurs. Une fois l'instrumentation de code terminée avec l'analyseur de code, régénérez et redéployez l'application monolithique Java .

L'instrumentation du code source est une fonction obsolète de l'analyseur de code. L'instrumenter binaire est l'option recommandée pour la collecte des traces d'exécution lors de l'exécution de cas d'utilisation métier, ce qui élimine la nécessité de régénérer et de redéployer l'application monolithique Java .

Prérequis

Assurez-vous de respecter la configuration système requise.

Procédure

  1. Placez le fichier d'archive binaire de votre application monolithique Java dans une structure de répertoire.

    Les formats de fichier archive Java valides incluent .cba, .class, .ear, .eba, .jaret .war. Les fichiers .rar et .zip qui contiennent les fichiers binaires d'archive Java sont également valides.

  2. Exécutez l'analyseur de code sur le fichier binaire de votre application.

    Exécutez la commande analyze. Pour obtenir de l'aide sur les commandes, ajoutez l'option -h .

    mono2micro analyze -a <binary-file-path>

    Les informations suivantes expliquent la syntaxe de la commande :

    • La variable <binary-file-path> est le nom de chemin du fichier binaire de l'application à analyser. Par défaut, la commande analyze crée un répertoire appelé binary-file-mono2micro dans le répertoire de travail de l'utilisateur avec plusieurs fichiers JSON.

      Vous pouvez ajouter l'option -o afin de spécifier le chemin de répertoire de sortie pour les fichiers JSON générés. L'utilisateur qui exécute l'analyseur de code doit disposer d'un accès en lecture et en écriture au répertoire /<output-dir-path>/ .

      mono2micro analyze -a <binary-file-path> -o <output-dir-path>
    • Vous pouvez générer une configuration pour l'instrumenter binaire qui envoie les traces au flux de sortie standard. Par défaut, l'instrumenter binaire utilise le code Java avec des instructions System.err.println() pour générer des traces d'exécution IBM Mono2Micro dans le flux d'erreurs standard. La définition de l'option --instrumentation-target sur la valeur out s'applique également à l'instrumentation source si la commande mono2micro instrument a été utilisée.

Exemples d'erreur standard et de flux de sortie standard

Pour le flux d'erreurs standard, exécutez la commande suivante :

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

Pour le flux de sortie standard, exécutez la commande suivante :

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

Contrôle de la liste des packages Java pour l'analyse binaire

L'analyseur binaire inspecte toutes les classes Java du fichier binaire, à l'exception des packages exclus par défaut. Vous pouvez vérifier la liste par défaut des packages exclus avec l'option -h .

Les options suivantes sont exclusivement utilisées pour contrôler les packages Java à analyser avec l'analyseur binaire. Aucune des options n'est conservée car l'analyseur ne sauvegarde aucune liste ou préférence utilisateur. Par conséquent, vous devez spécifier les options souhaitées pour chaque exécution. Pour les options, spécifiez une liste séparée par des virgules sans espaces vides, par exemple:
com.test.app,org.xyz.lib,edu.abc
--add-to-exclude-packages
Ajoute des packages à la liste par défaut des packages à exclure. L'analyse binaire exclut les packages de liste par défaut ainsi que la liste des packages spécifiés par cette option.
--exclude-packages
Exclut de l'analyse binaire la liste des packages spécifiés par cette option. Toutes les classes, à l'exception de celles de ces packages spécifiées par l'utilisateur, sont analysées, ce qui signifie que la liste de packages par défaut est ignorée.
--include-packages
Analyse uniquement la liste des packages spécifiés par cette option lors de l'analyse binaire. Etant donné que seules les classes de ces packages sont analysées, la liste des packages par défaut est ignorée.
--analyze-all
Force l'analyse de toutes les classes et de tous les packages.

Résultats

Une fois l'analyse terminée, si aucun répertoire de sortie n'est spécifié, l'analyseur de code crée un répertoire appelé binary-file-mono2micro sur le répertoire de travail de l'utilisateur avec plusieurs fichiers, où binary-file est le nom du fichier binaire Java analysé. Par exemple, si le fichier binaire est daytrader-ee7.ear, l'analyseur de code crée un répertoire nommé daytrader-ee7-mono2micro dans le répertoire de travail de l'utilisateur. Si l'option de sortie est spécifiée, les fichiers JSON sont placés dans le répertoire fourni.

Après analyse, le répertoire contient les fichiers suivants:

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

Les fichiers symTable.json et refTable.json contiennent des métadonnées sur des classes analysées telles que leurs noms, emplacements, noms d'attribut, constructeurs et méthodes. Le fichier instrumenter-config.json fournit la configuration de l'instrumenter binaire. Le fichier recommender-config.properties indique l'emplacement de votre archive d'application Java sur le disque et les packages qui ont été exclus ou inclus lors de l'analyse.

Si l'instrumentation source a été activée sur l'analyseur de code, le répertoire homologue contient également une copie du code source instrumenté avec des instructions System.err.println() que vous utiliserez ultérieurement pour générer des traces d'exécution IBM Mono2Micro .

L'instrumentation de l'analyseur de code n'imprime jamais la valeur des variables de votre application. L'objectif de l'instrumentation est d'enregistrer les flux temporels via diverses méthodes et constructeurs de classes, et non les valeurs des variables pendant l'exécution.

Limitations actuelles

  • Lorsque vous compilez du code instrumenté par l'analyseur de code, vous pouvez rencontrer leunreachable codeerreur de compilation. Dans certains cas, l'instrumentation de l'analyseur de code peut insérer des instructions d'instrumentation que le compilateur Java détecte comme étant inaccessibles.

    Pour résoudre ce problème, supprimez ou mettez en commentaire ces instructions inaccessibles. Leur suppression n'a aucune incidence sur la génération des traces d'exécution.

  • Lorsque vous exécutez l'analyseur de code, vous risquez de rencontrer une erreur liée à une insuffisance de mémoire dans le processus Java . Pour résoudre ce problème, définissez la variable d'environnement --java-opts en indiquant comme valeur une taille maximale de segment de mémoire.

    Par exemple, pour spécifier une taille de segment de mémoire Java maximale de 512 mégaoctets, exécutez l'une des commandes suivantes.

    mono2micro analyze -s <src-dir-path>  --java-opts "-Xmx512m"
    mono2micro instrument -s <src-dir-path>  --java-opts "-Xmx512m"
  • Lorsque l'analyseur binaire trouve plusieurs classes Java ayant le même nom et le même nom de package, il analyse la première classe identifiée et ignore les autres classes ayant le même nom et le même nom de package. Des noms en double peuvent se produire si la même classe est conditionnée dans plusieurs fichiers binaires au sein de l'archive binaire. Dans ce cas, un avertissement est consigné pour signaler les doublons trouvés. Dans la plupart des cas, ce n'est pas un problème, surtout si les classes trouvées sont identiques. Cependant, cela peut être un problème si les classes trouvées ont des différences dans leur structure.

Etape suivante

Si vous souhaitez obtenir des recommandations de partitionnement basées sur la logique métier de l'application, exécutez vos applications monolithiques Java avec une instrumentation pour générer des fichiers de trace d'exécution. Si, au contraire, vous souhaitez obtenir des recommandations plus rapidement, basées uniquement sur l'analyse statique de votre application, vérifiez les données collectées, puis exécutez le moteur d'IA. Vous utilisez les informations de l'analyseur de code, et éventuellement de l' instrumenteur binaire et de l' enregistreur de cas d'utilisation, comme données d'entrée du moteur d'IA, qui génère des recommandations de partition. Il est important de conserver votre fichier archive d'application Java au même emplacement sur le disque afin que le moteur d'IA puisse l'analyser plus en détail lors de l'étape de recommandation de partition.

Si vous avez choisi de collecter des fichiers de trace d'exécution via l'instrumentation source, une fois que l'analyseur de code a terminé avec succès le processus d'instrumentation, vous pouvez générer et déployer l'application instrumentée dans des environnements non productifs mais représentatifs. Suivez le processus exact que vous utilisez pour créer et déployer l'application d'origine. Selon les environnements, les applications et leurs versions instrumentées peuvent être sur des machines bare metal, des machines virtuelles ou des conteneurs.