differences between ms sql microsoft's jdbc drivers and jTDS's driver

Question

What are the differences between each driver? I mean, besides one of them being open-source

What are the pros / cons of each one?

Which one would you recommend?

---

here's jTDS own opinion on the subject: http://jtds.sourceforge.net/

Answer 1

They are distinct implementations. The jTDS driver is a type 4 and in my experience has better performance. I have been using the jTDS driver in a production environment without any issues for 5 years.

I would recommend going with jTDS.

Answer 2

While for many years jTDS was much superior than buggy mssql's own driver, the things are changing to the opposite recently.

Here is qoute from https://confluence.atlassian.com/bitbucketserver/transitioning-from-jtds-to-microsoft-s-jdbc-driver-776640388.html:

Why change drivers?

Recent releases of Hibernate, which Bitbucket Server uses to simplify its persistence layer, have introduced a requirement that the JDBC drivers and connection pools used be JDBC4-compliant. JDBC4 was introduced with Java 6.

The jTDS driver used by releases prior to Bitbucket Server 2.1 is a JDBC3 driver, compatible with Java 1.3, and therefore cannot be used with newer versions of Hibernate. While jTDS 1.3.0 and 1.3.1 claim to implement JDBC4, and JDBC4.1, they actually don't. The new methods have been "implemented", but their implementations are all throw new AbstractMethodError(), which means they can't actually be used. (See an example here, on GitHub.)

Since jTDS 1.3.1 does not provide a functioning JDBC4 implementation, the decision was made to replace jTDS with Microsoft's own SQL Server driver. Microsoft's driver is actively maintained, where jTDS hasn't been updated since 2014 (and prior to the small round of updates done in 2014 it hadn't been updated for multiple years). Microsoft offers a full JDBC4.2 (Java 8) driver and supports all the features of SQL Server, including SQL Server 2016.

Answer 3

One relevant difference is, that the JDBC 4.0 Implementation of the JTDS-Driver (v1.3.1) requires at least Java 7, whereas the JDBC 4.0 Implementation of the Microsoft driver is available in Java 6.

This is important if you want to use Hibernate 4.3 (relying on JDBC 4.0 API) and support Java 6. In that case JTDS is not an option.

Answer 4

The key reason FOR using jTDS is that it uses the lesser GPL license where Microsoft's driver uses their own license which has much more restrictions to it. One restriction of note is that you may not

• work around any technical limitations in the software

There are more restrictions within the license such as:

• transfer the software or this agreement to any third party
• use the software for commercial software hosting services

Which could be interpreted that you may not use it in production code, however earlier points in the license seem to allow it.

Having said all of this, I don't know of the licenses within SQL Server itself which may or may not restrict third-party drivers such as jTDS connecting to it.

Another point is that jTDS is available via maven, the Microsoft driver is not.

<dependency>
    <groupId>net.sourceforge.jtds</groupId
    <artifactId>jtds</artifactId>
    <version>1.3.1</version>
</dependency>

For my choice, use jTDS, it is more permissive and least likely to get you into trouble, and; it's a better driver.

Answer 5

jTDSperformance is good, but looks like the fail-over property is not supported by jTDS, if the SQL Server switches to secondary, needed to restart the application/server for picking the new ip and reseting the connection.

Answer 6

jTDS 1.3.1 (the latest released version) has problem with the TLS, what can be a game-changer for some people. The problems might have started with Java 8 - I saw such comment - but it's not verified. There's a "private", not released fix - see e.g. https://community.microfocus.com/cyberres/idm/w/identity_mgr_tips/19661/enforcing-ssl-tlsv1-2-jdbc-connection-via-jtds-jdbc-driver It worked for me. Below you can find an exception generated while trying to connect to the MS SQL using the original jTDS 1.3.1 and TLS:

java.sql.SQLException: Network error IOException: Connection reset
    at net.sourceforge.jtds.jdbc.JtdsConnection.<init>(JtdsConnection.java:436)
    at net.sourceforge.jtds.jdbc.Driver.connect(Driver.java:184)
    at java.sql.DriverManager.getConnection(Unknown Source)
    at java.sql.DriverManager.getConnection(Unknown Source)
    at jtds.JtdsMain.getData(JtdsMain.java:30)
    at jtds.JtdsMain.start(JtdsMain.java:15)
    at jtds.JtdsMain.main(JtdsMain.java:9)
Caused by: java.net.SocketException: Connection reset
    at java.net.SocketInputStream.read(Unknown Source)
    at java.net.SocketInputStream.read(Unknown Source)
    at net.sourceforge.jtds.ssl.TdsTlsInputStream.readFully(TdsTlsInputStream.java:131)
    at net.sourceforge.jtds.ssl.TdsTlsInputStream.primeBuffer(TdsTlsInputStream.java:100)
    at net.sourceforge.jtds.ssl.TdsTlsInputStream.read(TdsTlsInputStream.java:78)
    at sun.security.ssl.InputRecord.readFully(Unknown Source)
    at sun.security.ssl.InputRecord.read(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at net.sourceforge.jtds.ssl.SocketFactories$TdsTlsSocketFactory.createSocket(SocketFactories.java:101)
    at net.sourceforge.jtds.jdbc.SharedSocket.enableEncryption(SharedSocket.java:330)
    at net.sourceforge.jtds.jdbc.TdsCore.negotiateSSL(TdsCore.java:577)
    at net.sourceforge.jtds.jdbc.JtdsConnection.<init>(JtdsConnection.java:365)
    ... 6 more