EDIT: To expand upon my opinion; I do see the convenience of having a more simple way to process this. But it seems like something pretty silly to include when it would just bloat the API, and is simple to do ourselves.
Will your example work even when the server jar doesn’t include MySQL? Craftbukkit included the MySQL driver in their jar. (It’s what I was told) If your code works on Glowstone, then it doesn’t need the driver.
The main reason is to include a well documented database driver for everyone. Every mod who needs a database should use the same engine for a better administration. It will also reduce the “How do i install XYZ engine” posts.
Java already has well documented code for any type of database.
We already have methods available to us for databases. Including it in the API would just bloat it, create confusion, and eventually inspire debate about whether or not you should use native libraries, or the API.
Java has an API to work with JDBC drivers. You would still need to have the actual JDBC driver to be able to do anything with it. E.g. for MySql you need the MySql jdbc driver and for Sqlite you would need the Sqlite JDBC driver.
By default those drivers are not present on the system nor in the classpath.
This is not about creating a completely new API for database access, but to include a default db driver and pushing db configuration to the implementation instead of per plugin. You would still use the normal Java JDBC api to work with the database. The only difference is that you don’t manually make a connection, but get one from the API.
I would not want a database api to be included in the Sponge API itself. With a JDBC driver it is very easy to communicate with databases if you want. And then you are able to write your own little API if you need it.
And if you want to use an API, make it yourself and share it with the world.
Including a default driver in sponge would make it easier for the developers. Developers would know for sure that that driver is present and they would not need to include any other drivers(or instruct end-users on where to put the drivers).
As I said, this is not about building an abstraction layer on top of Java’s sql classes, but about moving connections and configuration to the sponge implementation. Meaning that databases and their connections are not defined in the configuration of every plugin that needs it, but that that is defined in the sponge config. That would make it easier to configure for the end users, as well as easier to use for the developers(no need to do config loading, no need to check config, no need to check if connection failed, etc).
EDIT: Just to clarify, adding a small connection API is not what the original poster asked. He just wants to have a default DB driver available that can be used. IMO it would be better that if they do include a DB driver that they then also would make a small DB connection API to reduce the amount of connection boilerplate and config(for both developers as well as end-users).
It would still be a normal java.sql.Connection… So yes, it would have a close method.
I feel like including a connection pool (like BoneCP or HikariCP) would help plenty of developers avoid novice mistakes, possibly lead to a plugin reloading system, and would be generally nice to have for JDBC apps.
My idea was to include a standard Driver for everyone and maybe build a wrapper for the plugins like the configuration framework in forge, so every dev have to use the same engine and maybe the same database with a data space and a configuration space for every plugin. Under this condition the sponge team can build an “Admin tool” to set the configuration for the plugins and the plugin developer are getting the possibility to read values from other plugins to integrate the own plugin as good as possible.