> Tech > JDBC 2.0 : les nouveautés

JDBC 2.0 : les nouveautés

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Richard Dettinger
Le JDBC 2.0 comprend plusieurs nouvelles méthodes, une fonction de mise à  jour batch et la prise en charge de types de données SQL3 Face à  l'expansion de l'univers Java, il est de plus en plus difficile de connaître toutes les nouvelles fonctions. La release de JDBC (Java Database Connectivity) 2.0 (qui est un élément standard de JDK (Java Development Kit) 1.2, ou Java 2) illustre bien cette rapide croissance des fonctionnalités. JDBC 2.0 offre de nouvelles fonctions intéressantes. En avant-première, cet article vous apprend à  utiliser ces nouvelles fonctions sur AS/400 en évitant les pièges. Sauf indication contraire, les exemples et les diverses méthodes de cet article s'appliquent également aux drivers JDBC natifs et AS/400 for Java Toolbox. (Pour plus d'informations sur JDBC et ses drivers, voir la bibliographie)
Avant de pouvoir utiliser JDBC 2.0, il faut bien sûr l'installer sur l'AS/400. Pour utiliser JDBC 2.0 avec le driver JDBC natif, il faut être en V4R4. On peut également l'obtenir sous la forme de la PTF 5769JV1 SF55645. Le support de JDBC 2.0 est standard sur l'OS/400 à  partir de la V4R5. L'utilisation de JDBC 2.0 avec le driver JDBC Toolbox est possible à  partie de la release Mod 2. Pour apprendre à  utiliser les nouvelles fonctions dans les releases JDK précédentes, voir l'encadré " Utiliser la fonctionnalité JDBC 2.0 dans JDK 1.1 ". Voyons maintenant de plus près comment fonctionne le JDBC 2.0.

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.

Téléchargez gratuitement cette ressource

Endpoint Security : Guide de Mise en œuvre

Endpoint Security : Guide de Mise en œuvre

Détournement d’applications légitimes, élévation de privilèges, logiciels malveillants furtifs : comment les solutions de Endpoint Security permettent elles de faire face aux nouvelles techniques d'attaques complexes ? Découvrez, dans ce Guide Endpoint Security, les perspectives associées à leur mise en œuvre.

Tech - Par iTPro.fr - Publié le 24 juin 2010