Finally!<p>Having dealt with <i>many</i> database drivers over the years, I can say first hand that closed source drivers are the bane of my existence. The only thing worse than running into a deep-in-the-stack bug in a database driver is one that you can't correct, let alone debug properly.<p>Regardless of your views on closed source software on the server side of things, it's a disservice to your customers to not have open source client side drivers. The secret sauce is always on the server side so it doesn't buy you anything. At best there's (very poor) argument for security through obscurity or you're doing something silly like hiding server side features behind client side feature flags.<p>Plus the more tech savvy of your users will directly contribute back to improve the driver. This is both for fixing existing bugs and adding features to support existing database server features. In this particular case, I've got a laundry list of things I'd like corrected / added / improved in the SQL Server JDBC driver. Had it been open sourced a few years back, I would have already done them myself.<p>Unless there's a legal restriction for not doing so, like say not owning the original source, there's no good reason not to open source the client side of things.
Yay... Isnt everyone using jTDS anyway because it is reliably faster?<p><a href="https://social.msdn.microsoft.com/Forums/en-US/36e7b9cf-5bc5-445d-874c-1d6f8e819b63/ms-jdbc-driver-performance-observations-versus-jtds?forum=sqldataaccess" rel="nofollow">https://social.msdn.microsoft.com/Forums/en-US/36e7b9cf-5bc5...</a><p><a href="http://stackoverflow.com/questions/7848213/why-is-jtds-faster-than-microsoft-jdbc-driver" rel="nofollow">http://stackoverflow.com/questions/7848213/why-is-jtds-faste...</a><p>Edit: seems like they fixed their abysmal performance after 5years in jan 2016; see stackoverflow comment.
Nice. Microsoft seems to be open-sourcing a fair bit of stuff lately.<p>However, unlike their other repos there are a couple of things that strike out. The code isn't even consistently formatted. There are parts that make you say ouch.
How did people use this before if it wasn't in the Maven Central Repo?<p>I know it's <i>possible</i> to not use mvn, just wondering what people did in cases like this where a possibly major component in the stack was unavailable. Most big stuff in Java can be found in mvn, and if not we often end up using an alternative. But that's not so easy for a driver.
Microsoft has been open-sourcing a lot lately, but it seems to be mostly "peripheral" software...<p><i>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.</i><p>...associated with the use of their commercial products.
Oh, this driver was really troublesome!<p>I remember we had once revert to java 6, because we couldn't get connectivity in Java 7 with SQL Server through their JDBC Driver... It took days to figure it out...
First off kudos to microsoft for open sourcing their JDBC driver.<p>I would have figured microsoft would have used a linter to fix style issues with their code before Open Sourcing.
E.x:
<a href="https://github.com/Microsoft/mssql-jdbc/blob/master/src/main/java/com/microsoft/sqlserver/jdbc/SQLServerColumnEncryptionJavaKeyStoreProvider.java#L81" rel="nofollow">https://github.com/Microsoft/mssql-jdbc/blob/master/src/main...</a><p>Anyone know if microsoft is going to specify their java style guide.