I think that building a unified DataSource API will actually not help
very much because the problem is that there is no standard interface for a
DataSource anyway.
However, there is a common configuration model, that of a JavaBean. This is easy to map to a GUI for configuration, and easy to map to XML for configuration files (e.g. the way a ManagedConnectionFactory is configured).
Even if Derby had a unified API, you still have to deal with differences in other DBMS implementations. So, in the end, the fact that Derby has different DataSource implementations is not disimilar to the situation where one has to deal with differences between the various DBMS vendors.
But all implementations follow the JavaBean model so it is fairly easy to write an application that can generically handle any vendor's implementation.
The advantage of a unified model is that there is only one implementation *within Derby.* Having multiple ones for one product depending on the JVM and transport in use is just confusing.
I have myself found it frustrating that there isn't a standard API for DataSources. It seems that the designers assumed you would always use JNDI, and did not really cater for J2SE or non-J2EE requirements.
That was the assumption. Although it may not be ideal, I still think it is easier than the original DriverManager solution.
-- Jeremy
