Dan raises an uncomfortable issue which I hope we don't have to address for this submission but which we do have to address for the 10.2 release. EmbeddedDataSource is just one instance of the problem. But it surfaces across the org.apache.derby.jdbc package.
The problem is that EmbeddedDataSource implements an interface (javax.sql.DataSource) which has changed between jdk1.4 and jdk1.6 in an irreconcilable way. In jdk1.6, DataSource contains a method with generics in its signature. If we ship an EmbeddedDataSource which implements this method, then I think it won't play well in a 1.4 vm. If, however, we ship an EmbeddedDataSource which does NOT implement this method, then on a 1.6 vm, EmbeddedDataSource will fail to satisfy the DataSource contract.
Here are some ways we could solve this problem:
1) Ship both a 1.4 and a 1.6 version of EmbeddedDataSource and sort the problem out at run time using some kind of classloader jiggery pokery. I'm waving my hands because I don't understand what the jiggery pokery would be.
2) Release two different distributions of 10.2, one for 1.5 and earlier vms and another for 1.6 vms.
3) Deprecate EmbeddedDataSource as a class in 10.2. Instead, turn it into an interface and add a factory to org.apache.derby.jdbc which is smart enough to contruct a vm-specific class at runtime. This solution could be applied to the other classes in that package which have the same problem.