JDBC 2.0 : les nouveautés

Comme on peut le voir à  la lecture de cet article, JDBC (Java Database Connectivity)
2.0 offre beaucoup de nouvelles fonctions intéressantes. Mais, comme JDBC 2.0
fait jusqu’à  présent partie de Java 2 (JDK 1.2), il faudra peut-être continuer
à  supporter Java 1.1. Est-ce à  dire que l’on ne peut pas profiter des nouvelles
fonctions ? Pas forcément. Considérez plutôt ces conseils comme une aide pour
aborder la nouvelle technologie.
Deux scénarii peuvent s’appliquer à  votre situation. Dans le premier, vous supportez
Java 1.1 et Java 2, en souhaitant que votre code ait deux voies : l’une pour la
nouvelle release et l’autre pour l’ancienne. Dans le second scénario, vous utilisez
actuellement la release Java 1.1 tout en souhaitant bénéficier des fonctions de
JDBC 2.0.
Dans le premier scénario, il faut déterminer au stade de l’exécution si vous avez
une JVM (Java Virtual Machine) Java 1.1 ou Java 2.Vous serez obligé de compiler
avec le JDK 1.2 (parce que vous utilisez les fonctions de Java 2 dans l’une de
vos voies de code), mais le code fonctionnera indifféremment avec Java 1.1 ou
Java 2. IBM traite depuis longtemps ce scénario en interne avec son  » bucket  »
de test JDBC. Un bucket de test est utilisé pour les fonctions de JDBC 1.1 et
JDBC 2.0. Le bucket détermine les tests qu’il doit effectuer selon le JVM sur
lequel il s’exécute.
Cette vérification peut se faire de plusieurs manières. Les interfaces du driver
JDBC ont une méthode getMajorVersion et une méthode getMinorVersion qui aident
dans ce genre de détermination, mais l’utilisation de ces méthodes est source
d’erreurs et d’incohérences entre les différents drivers JDBC. Je suggère d’essayer
au démarrage, de référencer une classe appartenant à  JDBC 2.0 puis d’intercepter
l’exception éventuelle.
Si on intercepte une exception (classe non trouvée), on fonctionne sur un runtime
Java 1.1. S’il n’y a pas d’exception, on fonctionne sur un runtime Java 2 (ou
ultérieur). L’exemple de programme de la figure A illustre cette technique.
Pour traiter le second scénario, on singularise l’objet JDBC au type d’implémentation
sous-jacent. L’interface de Sun limite les fonctions dont disposent les utilisateurs.
Dans son implémentation du driver JDBC, IBM utilise les mêmes classes pour JDBC
1.1 et JDBC 2.0.
Donc, quand on essaie d’accéder à  updateBatch dans le programme JDBC 1.1, la méthode
qui effectue le travail est vraiment présente, mais l’interface de Sun ne permet
pas d’y accéder. Si on singularise un objet Statement en un objet DB2Statement
(dans le cas du driver JDBC natif), on peut accéder aux fonctions de JDK 1.1.
Il est facile de déterminer les noms dont on a besoin.
Le driver JDBC natif ajoute DB2 devant les noms d’interfaces (DB2Statement, par
exemple). Le driver JDBC de l’AS/400 Toolbox for Java ajoute AS400JDBC devant
eux (AS400JDBCStatement, par exemple). Pour compiler un programme, il faut importer
les classes d’implémentation que l’on utilise.
La singularisation (typecasting) des objets a pour inconvénient de lier le programme
à  un certain driver JDBC. Mais des modifications mineures permettront par la suite
d’éliminer cette dépendance. L’exemple de programme de la figure B illustre ce
fonctionnement.