Drivers JDBC em Java

Um driver JDBC é a biblioteca fornecida pelo fabricante que converte chamadas genéricas do java.sql no protocolo de rede específico que o banco de dados entende. A API JDBC faz parte do JDK; o driver é um JAR externo que você adiciona ao classpath. Sem driver, sem conexão.

Este capítulo aborda os quatro tipos de driver (e por que apenas um importa hoje em dia), como o Java moderno carrega drivers automaticamente sem Class.forName, a diferença entre DriverManager e DataSource, e como o DriverManager decide qual driver trata determinada URL. Para uma visão geral de como a API JDBC se encaixa no todo, consulte Java JDBC Introduction; para agir em uma conexão ativa depois de obtê-la, consulte Java JDBC Connection.

Os quatro tipos de driver

A especificação JDBC define quatro tipos históricos de driver. Na prática moderna, você quase sempre usa o Tipo 4:

Os drivers do Tipo 4 — org.postgresql.Driver, com.mysql.cj.jdbc.Driver, o driver H2 — são apenas um JAR no classpath. É isso que você adiciona ao pom.xml ou build.gradle. Por serem pure Java, eles rodam em qualquer plataforma em que a JVM roda, sem nada para instalar na máquina host. Trate os tipos mais antigos como históricos: você os verá em documentações antigas e questões de exames, mas não os usará em código novo.

Carregando um driver: geralmente você não faz nada

Tutoriais antigos mostram Class.forName("com.mysql.cj.jdbc.Driver"). Desde o JDBC 4.0 (Java 6), essa linha é desnecessária. Os drivers incluem um arquivo META-INF/services/java.sql.Driver, e o DriverManager os registra automaticamente via mecanismo ServiceLoader na primeira vez que você chama getConnection. Portanto, o código moderno é simplesmente:

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

DriverManager vs. DataSource

Duas formas de obter uma conexão:

• DriverManager.getConnection(url, user, password) — a mais simples; boa para ferramentas, scripts e demos. Abre uma conexão física nova a cada chamada.
• DataSource — a abordagem preferida para aplicações e servidores. Um DataSource (geralmente respaldado por um pool de conexões como HikariCP) fornece conexões pooled, de modo que close() retorna a conexão ao pool em vez de encerrar o 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 */ }

A URL JDBC

Toda conexão começa com uma URL JDBC, que sempre tem o formato jdbc:<subprotocol>:<subname>:

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

O subprotocol (postgresql, mysql, h2, oracle, sqlserver) é a parte que decide qual driver trata a solicitação. Cada fabricante documenta seu próprio formato de URL e as opções que seguem o nome do banco de dados (configurações TLS, fuso horário, flags de conexão), por isso consulte a documentação do driver para a sintaxe exata.

Como o DriverManager escolhe um driver

Quando você chama getConnection, o DriverManager percorre sua lista de drivers registrados e pergunta a cada um "você reconhece esta URL?" via Driver.acceptsURL. O primeiro que responde sim é utilizado; se nenhum responder, você recebe No suitable driver found. Um driver normalmente responde "sim" apenas quando o subprotocol da URL corresponde ao seu próprio — por isso é o subprotocol, não o host, que roteia a requisição.

Um exemplo prático: inspecionando o registro de drivers

Este programa lista os drivers que o DriverManager conhece e, em seguida, pede que ele se conecte a três URLs de fornecedores diferentes — permitindo que você observe o contrato de correspondência de URLs em ação.

O que observar na execução:

• DriverManager.getDrivers() retorna os drivers registrados como uma Enumeration. Em um runtime sem JARs de driver, a lista está vazia — adicione postgresql.jar ao classpath e o Driver do PostgreSQL apareceria aqui automaticamente, sem nenhuma chamada a Class.forName.
• O subprotocol da URL (a parte após jdbc: — postgresql, mysql, h2) é o que cada driver corresponde. É assim que uma chamada a getConnection é roteada para o fornecedor correto: o driver reivindica seu próprio subprotocol.
• Cada URL falhou da mesma forma aqui porque nenhum driver está presente. Em uma implantação real, exatamente um driver reivindicaria cada URL; se você esquecer a dependência, verá precisamente esta mensagem "No suitable driver found" — um sintoma de JAR ausente, não de senha incorreta.
• O registro é automático via ServiceLoader, mas o JAR do driver ainda deve estar no classpath. A lição: um erro "No suitable driver" é um problema de build/dependência, corrigido no pom.xml, não no seu código Java.
• Driver expõe getMajorVersion/getMinorVersion, para que você possa registrar exatamente qual build do driver está em execução — útil quando um bug depende da versão do driver, não do seu código.

Assim que um driver está no classpath e getConnection retorna uma Connection ativa, o próximo passo é executar SQL por meio dela — consulte Java JDBC Connection e Java JDBC Statement.

Prática