db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5488) Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc.
Date Tue, 15 Nov 2011 15:18:51 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13150547#comment-13150547

Rick Hillegas commented on DERBY-5488:

Thanks to Bryan and Knut for helping me sort out what JDBC level our Java 6 drivers should

Except for the very highest JDBC level we support, all of our JDBC driver implementations
contain methods which were introduced by higher levels of the spec. So for instance...

1) Our JSR 169 implementation contains lots of methods which were introduced in JDBC 2.0 and

2) Our JDBC 3.0 implementation contains some methods which were introduced by JDBC 4.0.

Nevertheless, those implementations don't claim to fully implement the higher JDBC rev levels
from which they borrow methods.

JDBC 4.1 is an interesting special case. All other JDBC levels introduced data types which
did not appear in their predecessors. For this reason...

1') Our JSR 169 implementation doesn't contain an implementation of the java.sql.ParameterMetaData
type which was introduced in JDBC 3.0. A JDBC implementation which runs on small devices cannot
provide an implementation of ParameterMetaData and so can not claim to implement JDBC 3.0.

2') Our JDBC 3.0 implementation doesn't contain methods which mention java.sql.SQLXML, a type
which was introduced by JDBC 4.0. A JDBC implementation which runs on Java 5 cannot contain
methods which mention SQLXML and so can not claim to implement JDBC 4.0.

JDBC 4.1 is the first rev of JDBC which does not mention any types which were not available
to its predecessor. It is therefore the first rev of JDBC which could be implemented to run
on a lower rev level of the JVM.

So the short answer to Bryan's question about precedents is: No, there is no precedent. The
slightly longer answer to Bryan's question is: ...perhaps because the situation is impossible
for previous JDBC rev levels.


> Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc.
> -----------------------------------------------------------------------
>                 Key: DERBY-5488
>                 URL: https://issues.apache.org/jira/browse/DERBY-5488
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC, SQL
>    Affects Versions:
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>         Attachments: JDBC_4.1_Supplement.html, derby-5488-01-aa-objectMappingAndConversion.diff,
derby-5488-02-aa-fixBigInteger.diff, derby-5488-03-ac-moveDecimalSetterGetterAndTest.diff,
derby-5488-04-aa-fixBigIntegerDecimal.diff, derby-5488-05-ad-limitOffset.diff, derby-5488-06-aa-limitOffsetTests.diff,
derby-5488-07-aa-booleanObjects.diff, derby-5488-08-aa-extraLimitOffsetTest.diff, derby-5488-09-aa-jdbcMinorVersion.diff,
> In addition to the JDBC 4.1 bits which were visible in the Java 7 javadoc, a couple other
items appear in the JDBC 4.1 Maintenance Review spec. This spec has been published on the
JCP website at http://download.oracle.com/otndocs/jcp/jdbc-4_1-mrel-eval-spec/index.html.
I will attach a functional spec for the remaining bits.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message