I can't say that I fully understand the issue, but from what I gather the application in question is receiving some DataSource from somewhere and it (the application) needs to figure out whether or not that DataSource object is JDBC 4. I assume the app itself is not the one creating the datasource (if it was then it should theoretically know whether or not it instantiated the JDBC 4 Derby datasource class, shouldn't it?).
My inclination is to agree with Dan's comment above: "I think the only compliance indicator in JDBC is on Driver and Derby's driver is JDBC 4.0 compliant, but it doesn't really have a direct relationship to DataSource objects."
To me it seems odd to change Derby's connection objects to return a driver version of 3 for DataSources even though the connection and the driver are both JDBC 4.
One possible application-side workaround to this problem (if it's actually a problem with Derby, of which I am not sure) is to use reflection on the data source and then check the declared methods. Since EmbeddedConnectionPoolDataSource40 is a public class that we expect users/apps to be referencing directly, it seems like we should be able to suggest that applications code according to the public javadoc for that class:
Notice that all of the Derby *40 data source classes declare two public methods, both of which are required for JDBC 4:
public boolean isWrapperFor(Class<?> interfaces)
public <T> T unwrap(java.lang.Class<T> interfaces)
So if an application has some generic DataSource object and it wants to determine whether or not that data source is JDBC 4, one possible approach is to iterate through the declared methods and search for either of the above two. If "ds" is some DataSource object, we could do something like:
boolean isJDBC4DataSource = false;
java.lang.reflect.Method  mA = ds.getClass().getDeclaredMethods();
for (int i = 0; i < mA.length; i++)
String methodName = mA[i].getName();
if (methodName.equals("isWrapperFor") || methodName.equals("unwrap"))
isJDBC4DataSource = true;
Maybe this is too naive of an approach, but when I tried it on a simple repro it seems to have done the trick (i.e. isJDBC4DataSource remained false for the JDBC 3 datasource but was set to true for the JDBC 4 datasources). For what that's worth...