mssql-jdbc ships two jars because Java 8 is still in the wild

Type 4 means the protocol is spoken natively

The driver is described as a Type 4 JDBC driver that provides database connectivity to SQL Server through the standard JDBC application program interfaces available in the Java Platform, Enterprise Editions. It gives access to Microsoft SQL Server and Azure SQL Database from any Java application, application server or Java-enabled applet. The Type 4 classification is the important part for anyone choosing between drivers, because it means the driver speaks the database's native wire protocol directly rather than translating through an intermediate bridge or an ODBC layer. That is what makes it a reasonable default when the server is SQL Server, and it is also why it is not a general purpose option for talking to any database. The project is published under the MIT licence, and releases are on GitHub Releases, in the Microsoft JDBC documentation, and through Maven Central.

Two jars per release, because Java 8 will not die

Since preview release 12.1.0, each release contains two versions of the driver: one for use with Java 8, and one for use with Java 11 and above. The naming is jre8 and jre11, and the two are not just recompilations of the same source. The JRE 8 jar is described as JDBC 4.2 compliant, while the newer ones are built against the JDBC 4.3 API with partial support, and the documentation points at a support matrix listing which JDBC 4.3 features are actually implemented. The release history shows the line is still active: 13.6.1 is a hotfix and stable release from 2026-10-15, 13.6.0 a stable release from 2026-09-11, and 13.5.1 a preview release from 2026-07-31. The last push to the main branch was on 2026-10-19.

Building means proving the driver talks to a real server

The build prerequisites are Java 11 or newer, Maven 3.5.0 or newer, and an instance of SQL Server or Azure SQL Database that you can connect to. That last prerequisite is the one that surprises people. Maven builds automatically trigger a set of verification tests to run, and for those tests to pass you first need to add an environment variable called `mssql_jdbc_test_connection_properties` with the connection properties for your instance. In other words, this is not a library that compiles and ships; it is a driver that is tested by connecting to a database on every build, which makes sense for something where the wire protocol is the product. The Gradle path needs the same environment variable, and the same set of build profiles.

One profile per JDK, and the jar lands in a known place

The build profiles are named after the Java version they target, and the same list appears for both build systems. With Maven you run `mvn install -Pjre26` for a JRE 26 compatible jar, `-Pjre25` for 25, `-Pjre21` for 21, `-Pjre17` for 17, `-Pjre11` for 11, and `-Pjre8` for the JDBC 4.2 compliant jar built for JRE 8. The output lands in the `target` directory for Maven and in `build/libs` for Gradle, where the Gradle equivalent is `gradle build -PbuildProfile=jre26` and the rest of the profiles follow the same naming. Note the asymmetry in the JDK used to build: the jre8 profile is built with JDK 11 or newer, not with a Java 8 JDK, which is a reasonable way to keep the build toolchain modern while still producing an artifact that runs on Java 8.

The repository carries its own rules and licences

The top level of the repository is a good indication of how a vendor driver is actually run. There is a `pom.xml` and a `build.gradle`, so both Maven and Gradle builds are first class, plus a `maven-version-rules.xml` that presumably encodes the versioning policy. There is a `.checkstyle` directory, a `mssql-jdbc-checkstyle.xml` configuration and a `mssql-jdbc_formatter.xml`, so the code style is enforced by tooling rather than by review, and there are `Coding_Guidelines.md` and `coding-best-practices.md` documents alongside a `review-process.md`. A `CONTRIBUTING.md`, a `CODE_OF_CONDUCT.md`, a `SECURITY.md` and a `CHANGELOG.md` complete the usual set, and an `AGENTS.md` is present, which tells you something about how contributions are expected to be made now. One file deserves a note: the root also carries a separate licence file for the authentication component, distinct from the MIT licence at the root, so redistributing the driver with its authentication dependencies is worth checking against that file.

Where the project admits its gaps

The announcements section is short and unusually candid. The stated plan is to look into adding a more comprehensive set of tests, improving the javadocs, and starting development on the next set of features. That is a project describing itself as still in progress, which is a useful signal when you are deciding whether to depend on it. The build status table shows three separate Azure Pipelines definitions, for Windows, Linux and MacOS, each with its own badge, so the driver is built and tested on all three platforms continuously. The README also links a getting started guide for SQL Server and Java hosted in a separate examples repository, and there is a Gitter room for the SQL Server developers community plus a survey link asking how the project is doing.

Editorial conclusion

Adopt mssql-jdbc if you are connecting a Java application to SQL Server or Azure SQL Database through the standard JDBC API, since it is the vendor's own driver and the artifact you get from Maven is the one Microsoft ships. Do not adopt it if your environment is already on a JDK where a different driver is a better fit for your SQL dialect, since it targets one server. Verify first which jar variant you want, because a JRE 8 build is JDBC 4.2 compliant while the newer ones are built against JDBC 4.3 with partial support, and check the separate authentication licence file in the repository root before you redistribute the driver in a container image.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/mssql-jdbc on GitHub
4. README
5. Releases