You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2012/08/13 14:56:38 UTC

[jira] [Closed] (DERBY-5883) Simplify JSR-169 implementation class tree

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

Knut Anders Hatlen closed DERBY-5883.
-------------------------------------

          Resolution: Fixed
       Fix Version/s: 10.10.0.0
    Issue & fix info:   (was: Patch Available)

Committed revision 1372404.
                
> 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: 10.10.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>             Fix For: 10.10.0.0
>
>         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