It's an interesting idea but the details may make it not possible, for example References don't exist in J2ME.
Also since in the most case applications do not use Derby's or any DataSource implementation classes directly, I don't see how such a change would affect application code.
I'm not convinced that the api will end up being simpler, yes there would only be one class name for the Derby data source implementation, but now there will be more properties and properties that do not apply to certain connection types. E.g. the single data source would need to have the port and server properties, but these are not relevant in an embedded mode, so is the api simpler because of that? The code and api will also have to define and implement rules about how those properties behave, e.g. if conflicting properties are set, what happens.
A concrete proposal would be great, so we can see what is being made simpler, and how much simpler.
Strawman committed into a branch - not all possible properties are included but I figure that's just a matter of detail.
The main changes are: * DerbyDataSource is the implementation expected to be used by end user applications (both J2SE and J2ME). This implements the basic DataSource API returning a single physical connection.
* ReferenceableDataSource is now a subclass rather than a base class. The reasoning is that it would only be used to bind data sources into a JNDI server that did not support Java Objects; this is a fairly specialized usecase. The only reason this is separate is because J2ME CDC/FP 1.0 does not support javax.naming.
* The intention is to use the same API for both client and server connections. The ConnectionFactory would create the appropriate Connection implementation depending on the properties in the DataSource. For example, if the networkProtocol is specified as "drda" and/or the serverName is non-null then a client connection would be created; if the protocol is "embedded" and/or serverName is null then we would create an embedded server. This makes the application code unaware of the physical location of the database. Yes, more concrete definition is needed for the semantics here.
* The Driver implementation now uses the DataSource implementation (without using the actual interface so we can continue to support JDBC 2.0 core) rather than the other way around. This seemed like a natural refactoring given the approach adopted by JSR169.
-- Jeremy
