Commented by: @mrotteveel

Oracle, in all their wisdom added a method getParentLogger() to almost all JDBC interfaces. The signature of this method has throws SQLFeatureNotSupportedException instead of throws SQLException. As SQLFeatureNotSupportedException was only introduced in Java 6 / JDBC 4.0 this is highly annoying as it is hard to maintain compatibility with JDBC 3.0.

To implement JDBC 4.1 we will either need to:
1) Add a 'java.sql.SQLFeatureNotSupportedException' class in the jdbc 3.0 / Java 5 implementation to satisfy the signature
or
2) Make a lot of classes abstract and add separate implementations for JDBC 4.0/4.1 and JDBC 3.0 which is a lot of work because these methods are all over the place.

In both cases it is probably advisable to change the superclass of FBDriverNotCapableException to SQLFeatureNotSupportedException (at least for 4.0/4.1) as it matches the intent described for SQLFeatureNotSupportedException.

Given the amount of work option 2 introduces, my preference would be to go for option 1.

Commented by: Roman Rokytskyy (rrokytskyy)

What about creating an exception FBFeatureNotSupported in src/jdbc30 and src/jdbc40 directories, and for JDBC 3.0 it would be inherited from SQLException and for JDBC 4.0 from SQLFeatureNotSupportedException exception.

Also, if I am not mistaken, almost all concrete implementations of java.sql.* interfaces are already in src/jdbc20, src/jdbc30 and src/jdbc40 directories in order to solve the method issues. So, we can keep the getParentLogger() in src/jdbc41 directory.

Commented by: @mrotteveel

Unfortunately they added it to CommonDataSource, Driver and some other classes as well, which means that there are about 10 to 20 classes more which would need a counterpart in both jdbc30 and jdbc40. My reason for suggesting to add a java.sql.SQLFeatureNotSupportedException to jdbc30 was more that it prevents code duplication, and would make it easier to keep all code in one place.

But now I am typing this, I realise adding a superclass (eg AbstractCommonDataSource in jdbc30 and jdbc40 and having all datasources inherit from that would probably also work.

I don't think that we need to add a FBFeatureNotSupported, as FBDriverNotCapableException already has the semantics which JDBC 4.0 introduced with SQLFeatureNotSupportedException, so moving it in the exception hierarchy for 4.0 (and putting it in jdbc40 and jdbc30) would make those methods which already throw that exception also more compliant.

Commented by: @mrotteveel

Made changes in my local workspace (and corrected some issues I had introduced earlier for Java 5) in the way of my previous comment. Also implemented closeOnCompletion / isCloseOnCompletion.
Changed the build scripts by pretending that jdbc.40 / jdbc.41 / jdk1.6 / jdk1.7 are all the same (as they use the same sources).

Currently one test is broken for Java 7 from the commandline, but not from within Eclipse. Will commit once I have identified the problem.

Commented by: @mrotteveel

Test was actually not broken, but uncovered a genuine bug, which depended on the global execution order of iscCreateDatabase and iscAttachDatabase. If iscCreateDatabase was the first to be called (in the global execution of a Java process), some member variables of AbstractJavaGDSImpl were not set, if iscAttachDatabase was not called before calling iscDsqlPrepare, iscDescribe or iscDescribeBind these calls would fail.
These member variables were set if iscAttachDatabase was called (and from then one, would be available for all connections).

See JDBC190

Commented by: @mrotteveel

Committed changes for minimal JDBC 4.1 support, I still need to add some additional tests for closeOnCompletion support.

Commented by: @mrotteveel

Moved closeOnCompletion work to JDBC191