db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5883) Simplify JSR-169 implementation class tree
Date Fri, 27 Jul 2012 08:05:34 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-5883:

    Attachment: d5883-1a.diff

Attaching d5883-1a.diff, which makes the following changes:

1) Removes EmbedResultSet169, EmbedPreparedStatement169, EmbedCallableStatement169

2) Makes EmbedResultSet, EmbedPreparedStatement and EmbedCallableStatement non-abstract

3) Makes Driver169 create instances of EmbedResultSet, EmbedPreparedStatement and EmbedCallableStatement
instead of the classes with the "169" suffix

4) Removed references to the removed classes from build.xml, and also updated it to use jsr169compile.classpath
when compiling the classes that are supposed to work on CDC/FP

5) Removed an unused import in ViewDescriptor.java. Although this sounds like an unrelated
change, this import in fact made the build pull in many implementation classes when building
one of the iapi targets. This made it compile the classes touched by this patch using the
wrong classpath, which resulted in build errors after they were made non-abstract (the classes
were compiled against the JDBC 3 interfaces, but only implemented the JSR-169 subset)

I ran suites.All on Oracle Java ME Embedded Client 1.1, and suites.All and derbyall on Java
7. All tests passed.
> Simplify JSR-169 implementation class tree
> ------------------------------------------
>                 Key: DERBY-5883
>                 URL: https://issues.apache.org/jira/browse/DERBY-5883
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: d5883-1a.diff
> The JSR-169 interface is a subset of JDBC 3.0, but still the JDBC 3.0 implementation
classes do not extend the JSR-169 implementation classes. Instead, the JSR-169 and JDBC 3.0
implementation classes extend a common base class. The reason for this structure, is that
the JSR-169 compile targets used to be optional, so the JDBC 3.0 classes could not depend
on them.
> For example, the class javadoc comment for EmbedResultSet169 says:
>  * ResultSet implementation for JSR169.
>  * Adds no functionality to its (abstract) parent class.
>  * If Derby could be compiled against JSR169 that the parent
>  * class could be the concrete class for the environment.
>  * Just like for the JDBC 2.0 specific classes.
>  * Until that is possible (ie. easily downloadable J2ME/CDC/Foundation/JSR169
>  * jar files, this class is required and is only compiled by an optional target.
> Since the JSR-169 code is no longer optional, we should do as the comment suggests, and
use the base class directly instead. This would allow us to simplify the class tree.

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