Thanks, Rick. Here are some comments, in-lined between your points.
> 1) There are no interfaces in the 10.9 public api for the jdbc package. I see that you are introducing several interfaces in that package. Do those interfaces need to be part of the public API?
Probably not. I use them on an application level in the tests to avoid having the code have to decide at compile-time whether it will run with JNDI or not, cf my use of Class.forName there to create the data sources. The interface allows type-safe calls to the setters and getters, which would otherwise need to be called via reflection. But for user code this flexibility may not be strictly needed, what do you think? It may not carry its weight... See e.g. this section of the test J2EEDataSourceTest#testClientDSConnectionAttributes:
// now with ConnectionPoolDataSource
cpds = (ClientConnectionPoolDSI)Class.forName("org.apache.derby.jdbc.NonJNDIClientConnectionPoolDataSource40").newInstance();
cpds = (ClientConnectionPoolDSI)Class.forName("org.apache.derby.jdbc.ClientConnectionPoolDataSource").newInstance();
> 2) Similar question: You have introduced a new EmbeddedBaseDataSource class. Does this class need to be part of the public api?
No, I don't think it needs to be. ReferenceableDataSource wasn't part of the API either (which currently implement the getters and setters, e.g. setUser/getUser).
But note that ClientBaseDataSource is part of the public API, so I included EmbeddedBaseDataSource by analogy. Comment?
> 3) EmbeddedConnectionPoolDataSource, EmbeddedDataSource, EmbeddedXADataSource, EmbeddedConnectionPoolDataSource40, EmbeddedDataSource40, and EmbeddedXADataSource40 no longer implement ObjectFactory. That is a change to the public api which should be easy to fix.
Yes, but ReferenceableDataSource still implements it. It's just not inherited by the DSes anymore.
And the JNDI-full DSes still implement Referenceable. Isn't that sufficient? Not quite sure what you mean by "should be easy to fix"...
> 4) The inheritance hierarchy has been changed for several classes. The changes involve removing classes which were NOT part of the public api and inserting new classes which probably don't need to be part of the public api. These changes could affect code which crawls up the hierarchy via, for instance, calls to super(). In order for this to affect applications, however, they would have to crawl up the hierarchy through classes which are not part of the public api. I do not think it is likely that anyone does this. And if they do, I think your warranty is violated when you crawl into classes which are not part of the public api. This issue is probably worth a release note but I don't think that it is a significant change to the public api.
> 5) ClientBaseDataSource no longer implements javax.naming.Referenceable. In my opinion, this is the most serious change to the public api. This is an abstract class, so no one can directly instantiate one of these things. However, someone writing a test framework might use this abstraction in order to factor out tests which should be run against different Derby DataSources. Such a framework might be interested in the fact that ClientBaseDataSource implements Referenceable.
OK. Any suggestions?