Open Sourcing the Microsoft JDBC Driver and Maven Support
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
Having dealt with many 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.
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.
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.
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.
This reminds me far too much of the .NET DB2 drivers. What a steaming pile, not to mention having to navigate the labyrinth of the IBM download site to even find it in the first place.
"Hi $BIG_COMPANY, we'd like to expand our usage of $SOFTWARE that we've already got a $BIG_MONEY license for. Where can we get client drivers for a new app that will use it?"
"Hi $CUSTOMER, that's great news. Send us a check for $MORE_MONEY and we'd be happy to help."
"Hi $BIG_COMPANY, to clarify, we're already paying $BIG_MONEY for a license for the server and we'd like to expand our usage of it. That means in the longer term we'd be more entrenched into using it and would likely renew your contract."
"Hi $CUSTOMER, that's great news. Send us a check for $MORE_MONEY and we'd be happy to help."
Porting a .NET application build for MS SQL to DB2 and dealing with all the ... pecualiarities of the DB2 driver is something I will hopefully never have to do again.
Not so much anymore? The tendency is towards smarter clients and possibly dumber servers.
cf Kafka
Also fast switchover in Oracle's JDBC drivers requires some code outside what is required by JDBC api.
https://social.msdn.microsoft.com/Forums/en-US/36e7b9cf-5bc5...
http://stackoverflow.com/questions/7848213/why-is-jtds-faste...
Edit: seems like they fixed their abysmal performance after 5years in jan 2016; see stackoverflow comment.
https://sourceforge.net/p/jtds/discussion/129584/thread/050f...
But I just cant stand the loving hype for MS here. They gave out such horrible and dog slow drivers to their paying customers that people reverse engineered the protocol and wrote their own. And it still performs very well.
Now that MS publishes this codebase (which should have been standard, or at least best, practice), they get showered with love.
Like an abusive relationship where one is happy and extatic if the abuser is reasonably nice for a day.
While Microsoft claims the new driver is fully JDBC 4.1 compliant key JDBC 4.1 methods throw SQLFeatureNotSupportedException and the code is littered with comments
// The driver currently does not implement JDDBC 4.1 APIs
Now it's your turn, Oracle.
That'll never happen. They're too busy trying to make the open source projects they inherited from Sun (MySQL, Java) closed source again.
Still not totally happy with their direction on Java
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.
I know it's possible 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.
Not recommended, but plenty of folks do it.
Here's a nice article explaining how to do it: https://devcenter.heroku.com/articles/local-maven-dependenci...
The driver is only needed at run time, not compile time, at least in this case.
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.
...associated with the use of their commercial products.
How is .NET Core peripheral software? If anything it enables developers with C# codebases to move away from Microsoft's commercial products.
MSSQL, on the other hand...
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...
I would have figured microsoft would have used a linter to fix style issues with their code before Open Sourcing. E.x: https://github.com/Microsoft/mssql-jdbc/blob/master/src/main...
Anyone know if microsoft is going to specify their java style guide.
I'm sure that they'd appreciate help in cleaning it up.