Hi. There is no meaningful alternative to JDBC for connecting to DBMSes from Java.
There are higher-level APIs, but they will be using JDBC internally. At the wire level,
the protocol to talk to a DBMS is proprietary to the DBMS. Typically the DBMS vendor
provides a publicly usable native library API. This API is used by type-2 JDBC
drivers. Type-4 (all-java) drivers understand the wire level protocol and the vendor
implements the wire level protocol in Java to implement the JDBC calls. Typically DBMS
vendors provide extensions to JDBC to execute any special functionality that their
wire-level API offers that goes beyond standard JDBC.
   As such, there is no value in re-implementing the wire-level protocol for a non-JDBC
API, especially when JDBC is part of the standard that makes Java so productive.

Joe Weinstein at BEA

There are a few possible answers, depending on what you mean.

First of all, not all databases are relational, but all commonly used
databases are relational.  Non-relational databases won't use JDBC,
since it's built strongly around the relational model.  This isn't so
much about competitors to JDBC, as about competitors to relational
databases.

JDBC is practically universal in the relational database space in Java.  
There is not, to the best of my knowledge, any existing relational
database access API for Java that is as widespread or that provides
access to as many DBMS options as JDBC... nor is there anything even
close.  (There is a specific tool for Oracle called SQLJ that doesn't
appear to be based on JDBC, but I could be wrong about that; and the
tool is specific to the Oracle DBMS.)

If you're looking from a cross-platform perspective, though, then ODBC
certainly competes against JDBC.  Much like the object vs. relational
database scenario, though, they have to compete in the context of their
respective language choices.  That is, JDBC might be a reason to choose
Java as a language for implementation (it's almost universally
considered superior to ODBC), but Java and ODBC in combination is simply
not a viable choice for deploying a realistic application.

It's also occasionally true in casual usage that "JDBC" is used as a
synonym for "plain JDBC", meaning that software is developed to use JDBC
directly to connect to the database.  That is certainly not the only
option, and "plain JDBC" definitely does compete with other
technologies: Oracle TopLink, Hibernate, JDO, EJB-CMP, CocoBase, Castor,
etc.  These other options use JDBC as part of their implementation
(excepting some of the more abstract ones like JDO, which as a
specification doesn't rely on JDBC but in practice non-JDBC-based JDO
implementations are not based on relational databases).

The advantage of the latter O/R mapper products listed is that they
provide a higher-level, more object-oriented, and easier way to interact
with the database.  A product using these technologies may or may not
also use JDBC directly.  Some technologies (e.g., Hibernate) visibly
depend on JDBC and practically encourage dropping down to the JDBC level
for solving some performance bottlenecks.  Others (e.g., JDO) make it a
design goal to hide JDBC entirely, such that it's possible to provide
implementations that are based on XML files or object databases, rather
than relational databases; so it's clearly harder to mix them with JDBC.

I'm sure that's more than you wanted to know...

JTDS or JavaTDS. It is a binary stream format for SQL Server.
It can be found at Sourceforge