Open sourcing the Microsoft JDBC Driver and Maven support

We are excited to announce the open sourcing of the Microsoft JDBC Driver for SQL Server! By open sourcing the driver, we hope to get quicker feedback from the community, release on a faster cadence, and develop new features based on the scenarios Java developers need to support. Please check out the announcement video.

Open sourcing the driver includes:

  • Java source code on GitHub under MIT license
    • We hope developers will participate in developing the driver with us by filing issues and making pull requests
  • Build scripts for Maven and Ant
    • Build your own jars to support either JDBC 4.1 specification (for use with JRE 7) or JDBC 4.2 specification (for use with JRE 8)

With open sourcing, we have finally made the driver available on the Maven Central Repository. We have two jars available to support JRE 7 or 8. They can be selected by changing the version – “6.1.0.jre8” or “6.1.0.jre7”. Add the JDBC driver to your Maven project by adding the following code to your POM file to include it as a dependency in your project.


The JDBC driver can be used to connect to SQL anywhere. Use it to connect to SQL Server (on-prem or in the cloud), Azure SQL Database, and Azure SQL Data Warehouse. Feature support for the JDBC driver has carried over from our JDBC Driver 6.0. This includes support for:

  • Always Encrypted
  • Azure Active Directory authentication
  • Table-Valued Parameters
  • Internationalized Domain Names (IDN)
  • Extended support for Parameterized Queries
  • Bulk Copy
  • Transparent connections to AlwaysOn Availability Groups

We look forward to working together to bring value to Java developers using SQL Server. If you have any questions or issues, please report them on the GitHub repository. To get started with developing apps in your programming language of choice and SQL Server, check out our new tutorials.

Andrea Lam (Program Manager)

Comments (13)
  1. Ilyas Bakirov says:

    Good news, thanks Microsoft!

  2. Kapil says:

    It is currently failing to pull in the JDBC resource from the repo:
    [ERROR] Failed to execute goal on project test: Could not resolve dependencies for project test:jar:0.0.1-SNAPSHOT: Failed to collect dependencies at

    Failed to read artifact descriptor for

    Could not transfer artifact from/to central (
    Hostname not verified:

    1. Andrea Lam says:

      Hi Kapil,

      You’ll want to make sure you’re able to access the .m2 repository. Here’s some additional information:

      I am able to see the jar file in the repository:


      1. Andrea Lam says:

        Additionally, if you are behind a firewall, can you please run “mvn clean install -U” and try again?


  3. Bohdan Levchenko says:

    That’s a wonderful news! It’s time to replace jtds 🙂

  4. Vishnu says:

    Thats awesome. Thank you.

  5. Lotfi says:

    Great news, thanks !
    Would it be possible to deploy the x86/x64 sqljdbc_auth.dll DLLs also for integrated security on Windows? Can’t seem to find them anywhere 🙁

      1. Somebody who uses auth DLLs says:

        Yes, the DLLs can be found by that manual download, but it’d be helpful if they were also deployed via Maven (would need to be a separate artifactId to prevent version conflicts), or better yet included in any new versions of the existing artifacts.

        1. Andrea Lam says:

          Unfortunately due to licensing, it’s been difficult for us to upload the DLLs to Maven, but this is definitely something we have been considering.

          Andrea Lam
          Program Manager

  6. Hi folks

    This is great news. So any project can use the appropriate drivers on JRE7 and JRE8. Cheers for that.

    Our only concern is, that within the transient dependencies there are some version conflicts which are basically not resolveable.

    For example: net.minidev:json-smart is referenced in two distinct versions. One depending on a 1.x version and the other in a 2.x version. According to the project page for json-smart the two apis are not compatible. So which version should it be? When running a java application, the lib appearing first in classpath ususally winns and this version is used. This may lead to unexpected runtime erros.

    This is impossible to solve by the project using the library.

    What are your thoughts on that. Will you clean up these dependencies to produce a valid maven artifact?

    – Michael

  7. Very Good News. Thank you !

Comments are closed.

Skip to main content