Toutefois, avant que setup ne s'exécute, il y a une ou deux astuces dans le code. Si vous examinez les définitions de champs près du haut de la classe (non montré), vous verrez la ligne :
private String os_=getOperatingSystem();
Le premier bout d'information dont setup a besoin - le système
d’exploitation actuel – vient d’un appel adressé à getOperatingSystem, qui demande les propriétés de l’objet système intégré dans Java. La propriété » os.name » est simplement une chaîne avec la description la plus générique du système d’exploitation, comme » Windows NT » (aussi renvoyée par Windows 2000) ou » OS/400 « . Notons que getOperatingSystem a été conçu comme un utilitaire générique appelable par tout programme à tout moment.
Au premier appel, quand le champ local os_ est nul, la méthode getOperating System définit os_ et aussi une variable booléenne – os400_- qui indique si le système utilise ou non OS/400 (c’est-à -dire si le programme peut être extrait par n’importe quel programme, par la méthode isAs400). Lors d’appels successifs, getOperatingSystem saute l’initialisation et renvoie simplement le nom du système d’exploitation.
L’utilisation d’un trait de soulignement après les noms du champ de classe peut s’avérer très utile pour suivre l’emplacement de la déclaration d’une variable lors du débogage. Elle dispense également d’utiliser le préfixe this. quand on initialise une variable de classe à partir d’une variable locale à la méthode courante (par exemple, os400_=os400 par rapport à this.os400=os400).
Le système d’exploitation courant est tellement intégré à l’Object, que nous avons créé une garantie absolue que la valeur sera définie lors de l’instanciation en faisant l’appel de getOperatingSystem directement à partir de la définition de champ. Le champ est ainsi initialisé avant qu’aucun autre code constructeur ne s’exécute. Par conséquent, quand setup s’exécutera, il aura toujours une valeur de système d’exploitation non nulle à référencer. (De plus, les éventuels constructeurs supplémentaires que nous pourrions ajouter auront toujours une valeur définie.)
Le second sujet – déterminer si la connexion à l’iSeries nécessite un logon – dépend du fait que le système local est un iSeries ou non et, si oui, quelle version de l’OS/400 s’exécute. Pour les versions 4.3 et ultérieures, le driver hérite des attributs du job courant et ne nécessite pas de logon séparé (bien que le programme puisse, en option, se connecter (log on) avec un profil différent).
La méthode getVersion convertit la propriété système pour la version de l’OS (par exemple, » V4R4M0 » sur l’iSeries) en un format BigDecimal, plus pratique pour effectuer des comparaisons (et plus semblable au système de numérotation d’autres systèmes d’exploitation). J’ai choisi un chiffre unique pour la release avec un double chiffre pour la modification, simplement pour allonger l’espace avant le numéro de release plus significatif. Ainsi, V4R4M1 devient 4.401. Pour des comparaisons BigDecimal, un résultat de -1 indique que l’objet est plus petit que son argument, 0 indique des valeurs égales, et 1 indique que l’objet est plus grand que l’argument. Ainsi, setup compare la version de l’OS courant à 4.3 et définit le logon nécessaire, mustLogon_, en conséquence. Quelle que soit la version courante, un programme Java tournant sur l’iSeries peut utiliser les drivers DB2 UDB natifs. Ainsi, setup enregistre la classe du driver DB2 UDB, com.ibm.db2.jdbc.app.DB2Driver, en passant son nom de classe à la méthode Class.for-name. Il stocke également le driver dans le cas où nous souhaiterions plus tard examiner la sélection au moyen de la méthode getDriverClass.
Le nom de base pour l’URL de la base de données DB2 UDB (jdbc:db2) est différent de l’URL Toolkit (jdbc:as400:), donc le nom de l’URL est stocké dans la variable urlRoot_ pour extraction ultérieure via getUrlRoot. Pour que les programmes restent adaptables, il faut s’assurer qu’ils s’appuient sur getUrlRoot pour définir le nom de la base de données. A noter que si le chargement du driver DB2 UDB échoue, la clause catch (Exception) mettra le urlRoot_ à null. Nous pouvons utiliser ce réglage pour obliger le programme à essayer de charger les drivers Toolkit JDBC en cas de problème (driver manquant, définition de chemin de classe incorrecte, par exemple). La clause catch journalise également un message dans la file d’attente de sortie QPRINT par l’intermédiaire de la méthode System.println (en cas d’exécution en batch) ou vers la console système (en cas d’exécution interactive).
La dernière étape, le chargement du driver Toolkit JDBC, ne s’applique que si (1) le système d’exploitation n’est pas OS/400 ou (2) le chargement des drivers JDBC natifs a échoué. Dans ce dernier cas, le Toolkit JDBC (comme le driver DB2 UDB) journalise un message sur la console ou QPRINT.
Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.
