Anurag Shekhar (JIRA) wrote: > [ > http://issues.apache.org/jira/browse/DERBY-819?page=comments#action_12363013 > ] > > Anurag Shekhar commented on DERBY-819: > -------------------------------------- > > SQLExceptionFactory checks for jvm version and if the jvm version is jvm16 or > above > it will instantiate JDBC40ExceptionFactory. As JDBC40ExceptiopnFactory have > references of JDBC40 specific Exceptions it can't be loaded in jvm's prior to > 16. Thats why SQLExceptionFactory uses reflection to load and again uses > reflection to call getJDBC40Exception which returns JDBC40Specific exceptions. > > If the current JVM version is less that 16 it returns the > EmbeddedSQLException same as the way Util class was returning. > > If JVM version is 16 but JDBC40ExceptionFactory doesn't exist > (will happen if while building derby there was no jdk1.6) > it throws a SQLRuntime Exception indicating the derby.jar > doesn't have this class.
If derby.jar was built without JDBC 4.0 support then there should be no evidence of a JDBC 4.0 driver, the 3.0 driver should boot and work normally. If the exceptions are handled like all the other JDBC objects through the factory (InternalDriver and its sub-classes), then there is no need to have in-line code that checks the jvm version number. Dan.
