Pilotes Java JDBC et DriverManager

Un pilote JDBC est la bibliothèque fournie par le fournisseur qui traduit les appels génériques java.sql en protocole réseau spécifique compris par la base de données. L'API JDBC fait partie du JDK ; le pilote est un JAR externe que vous ajoutez au classpath. Sans pilote, pas de connexion.

Ce chapitre couvre les quatre types de pilotes (et pourquoi un seul compte aujourd'hui), la façon dont Java moderne charge automatiquement les pilotes sans Class.forName, la différence entre DriverManager et DataSource, et la manière dont DriverManager détermine quel pilote gère une URL donnée. Pour avoir une vue d'ensemble de la façon dont l'API JDBC s'articule, voir Java JDBC Introduction ; pour agir sur une connexion active une fois obtenue, voir Java JDBC Connection.

Les quatre types de pilotes

La spécification JDBC définit quatre types historiques de pilotes. En pratique moderne, vous utilisez presque toujours le Type 4 :

Type	Nom	Remarques
1	Pont JDBC-ODBC	Obsolète ; supprimé du JDK dans Java 8
2	API native	Encapsule une bibliothèque cliente C ; nécessite du code natif installé
3	Protocole réseau	Communique avec un middleware qui parle à la base de données
4	Pure-Java (thin)	Un seul JAR, tout Java, parle directement le protocole fil de la base de données

Les pilotes de Type 4 — org.postgresql.Driver, com.mysql.cj.jdbc.Driver, le pilote H2 — ne sont qu'un JAR sur le classpath. C'est ce que vous ajoutez dans pom.xml ou build.gradle. Étant en pur Java, ils fonctionnent sur toute plateforme supportée par la JVM, sans rien à installer sur la machine hôte. Considérez les types plus anciens comme historiques : vous les verrez dans d'anciens docs et des questions d'examen, mais vous ne les utiliserez pas dans du nouveau code.

Chargement d'un pilote : vous ne faites généralement rien

Les anciens tutoriels montrent Class.forName("com.mysql.cj.jdbc.Driver"). Depuis JDBC 4.0 (Java 6), cette ligne est inutile. Les pilotes embarquent un fichier META-INF/services/java.sql.Driver, et DriverManager les enregistre automatiquement via le mécanisme ServiceLoader la première fois que vous appelez getConnection. Le code moderne est donc simplement :

// No Class.forName needed — the driver JAR self-registers.
Connection conn = DriverManager.getConnection(
    "jdbc:postgresql://localhost:5432/shop", "app", "secret");

DriverManager vs. DataSource

Deux façons d'obtenir une connexion :

DriverManager.getConnection(url, user, password) — le plus simple ; adapté aux outils, scripts et démos. Ouvre une toute nouvelle connexion physique à chaque appel.
DataSource — l'approche préférée pour les applications et les serveurs. Un DataSource (généralement soutenu par un pool de connexions comme HikariCP) distribue des connexions en pool, de sorte que close() retourne la connexion au pool au lieu de fermer un socket.

HikariDataSource ds = new HikariDataSource();
ds.setJdbcUrl("jdbc:postgresql://localhost:5432/shop");
ds.setUsername("app");
ds.setPassword("secret");
try (Connection conn = ds.getConnection()) { /* borrowed from the pool */ }

L'URL JDBC

Chaque connexion commence par une URL JDBC, qui a toujours la forme jdbc:<subprotocol>:<subname> :

jdbc:postgresql://localhost:5432/shop
│    │           │
│    │           └─ subname: host, port, database, options
│    └───────────── subprotocol: identifies the vendor/driver
└────────────────── scheme: always "jdbc"

Le subprotocol (postgresql, mysql, h2, oracle, sqlserver) est la partie qui détermine quel pilote traite la requête. Chaque fournisseur documente son propre format d'URL et les options qui suivent le nom de la base de données (paramètres TLS, fuseau horaire, indicateurs de connexion) ; consultez donc la documentation du pilote pour connaître la syntaxe exacte.

Comment DriverManager choisit un pilote

Lorsque vous appelez getConnection, DriverManager parcourt sa liste de pilotes enregistrés et demande à chacun « reconnaissez-vous cette URL ? » via Driver.acceptsURL. Le premier qui répond oui est utilisé ; si aucun ne le fait, vous obtenez No suitable driver found. Un pilote répond généralement « oui » uniquement si le subprotocol de l'URL correspond au sien — c'est pourquoi le subprotocol, et non l'hôte, est ce qui route la requête.

Un exemple concret : inspecter le registre des pilotes

Ce programme liste les pilotes que DriverManager connaît, puis lui demande de se connecter à trois URL de fournisseurs différents — vous permettant d'observer en action le contrat de correspondance d'URL.

java— editable, runs on the server

import java.sql.DriverManager;
import java.sql.Driver;
import java.sql.SQLException;
import java.util.Enumeration;

public class JdbcDriversDemo {
  public static void main(String[] args) {
    // The driver layer: DriverManager keeps a list of registered Driver
    // implementations and hands a connection request to the first that
    // recognises the URL's subprotocol.
    Enumeration<Driver> drivers = DriverManager.getDrivers();
    System.out.println("--- registered drivers ---");
    if (!drivers.hasMoreElements()) System.out.println("(none on the classpath)");
    while (drivers.hasMoreElements()) {
      Driver d = drivers.nextElement();
      System.out.println(d.getClass().getName() + "  v" + d.getMajorVersion() + "." + d.getMinorVersion());
    }

// Each vendor URL has the shape jdbc:<subprotocol>:<subname>.
    String[] urls = {
      "jdbc:postgresql://db:5432/shop",
      "jdbc:mysql://db:3306/shop",
      "jdbc:h2:mem:test",
    };
    System.out.println("--- driver selection ---");
    for (String url : urls) {
      try {
        DriverManager.getConnection(url);
        System.out.println(url + " -> connected");
      } catch (SQLException e) {
        System.out.println(url + " -> " + e.getMessage());
      }
    }
  }
}

Ce qu'il faut retenir de l'exécution :

DriverManager.getDrivers() retourne les pilotes enregistrés sous forme d'Enumeration. Sur un runtime sans JAR de pilote, la liste est vide — ajoutez postgresql.jar au classpath et le Driver PostgreSQL apparaîtrait ici automatiquement, sans aucun appel Class.forName.
Le subprotocol de l'URL (la partie après jdbc: — postgresql, mysql, h2) est ce sur quoi chaque pilote se base pour correspondre. C'est ainsi qu'un appel getConnection est routé vers le bon fournisseur : le pilote revendique son propre subprotocol.
Toutes les URL ont échoué de la même façon ici parce qu'aucun pilote n'est présent. Dans un déploiement réel, exactement un pilote revendiquerait chaque URL ; si vous oubliez la dépendance, vous verrez précisément ce message « No suitable driver found » — symptôme d'un JAR manquant, pas d'un mauvais mot de passe.
L'enregistrement est automatique via ServiceLoader, mais le JAR du pilote doit toujours être sur le classpath. La leçon : une erreur « No suitable driver » est un problème de build/dépendance, à corriger dans pom.xml, pas dans votre code Java.
Driver expose getMajorVersion/getMinorVersion, ce qui vous permet de journaliser exactement quelle version du pilote est en cours d'exécution — utile quand un bug dépend de la version du pilote et non de votre code.

Une fois qu'un pilote est sur le classpath et que getConnection retourne une Connection active, l'étape suivante consiste à exécuter du SQL à travers elle — voir Java JDBC Connection et Java JDBC Statement.

Pratique

L'application moderne d'un collègue (Java 17) lève 'No suitable driver found for jdbc:postgresql://...' au démarrage. Quelle est la correction la plus probable ?

Ajouter le JAR du pilote JDBC PostgreSQL comme dépendance pour qu'il soit sur le classpath et s'enregistre automatiquementAjouter un appel 'Class.forName("org.postgresql.Driver")' qui est requis sur chaque JDK modernePasser de DriverManager à DataSource, car DriverManager ne peut pas charger les pilotes de Type 4Réduire la complexité du mot de passe de la base de données pour que le pilote puisse s'authentifier