[
https://issues.apache.org/jira/browse/DERBY-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-6213:
--------------------------------------
Attachment: descriptor-lists.diff
I took a look at the problems with generifying GenericDescriptorList and
ColumnDescriptorList, as well as DataDictionaryImpl.getDescriptorViaIndex() and
DataDictionaryImpl.getDescriptorViaHeap(). It looks like the compilation
problems Rick saw happen because CatalogRowFactory.buildDescriptor() is not
generified, so that it will have to return TupleDescriptor regardless of the
type of the list passed in to the getDescriptor* methods. Unfortunately,
generifying it wouldn't help much the way the code is structured currently,
because the dictionary gets the row factory instance via a couple of
indirections, one of which is through an array where any type parameters would
be lost.
There is however a trick that could be used. The getDescriptor* methods could
take a Class parameter that describes the expected type of the returned
descriptors. They can use the Class instance to do an explicit cast of the
value returned by CatalogRowFactory.buildDescriptor(), so that it can safely be
added to the list. There will still be a cast, but that cast will be hidden
inside the getDescriptor* methods, instead of having each caller cast the
descriptors to the desired sub-type like they do now.
The attached patch, descriptor-lists.diff, changes the descriptor list classes
so that they extend a more specific type, and it changes the signatures of
getDescriptorViaHeap() and getDescriptorViaIndex() so that they accept the more
specific list types. It also changes the callers of these methods, since
there's now an extra argument.
All tests passed with the patch.
> Deprecate support for Java 5 and CDC
> ------------------------------------
>
> Key: DERBY-6213
> URL: https://issues.apache.org/jira/browse/DERBY-6213
> Project: Derby
> Issue Type: Improvement
> Components: Build tools, Documentation, Javadoc
> Affects Versions: 10.11.0.0
> Reporter: Rick Hillegas
> Attachments: buildbreak2-datasource.diff, buildbreak.diff,
> client.diff, derby-6213-01-aa-collapsePublishedAPI.diff,
> derby-6213-02-aa-org.apache.derby.vti.diff, derby-6213-03-aa-misc.diff,
> derby-6213-03-ab-misc.diff, derby-6213-04-aa-vtiPackageOnJava7.diff,
> derby-6213-05-ab-misc2.diff, derby-6213-06-aa-convertProductToJava6.diff,
> derby-6213-06-ab-removeCDC.diff,
> derby-6213-07-aa-restOfProductExceptJDBC.diff, derby-6213-08-ab-jdbc.diff,
> derby-6213-09-ab-lint1.diff, derby-6213-10-aa-lint2-implServices.diff,
> derby-6213-11-aa-lint3-implStore.diff,
> derby-6213-12-aa-lint4-implSqlCatalog-implSqlDepend.diff,
> derby-6213-13-aa-lint4-implSqlConn.diff,
> derby-6213-14-aa-lint6-implSqlCompile-implSqlExecute.diff,
> descriptor-lists.diff, revive-sqlxmlutil-target.diff, testcode.diff
>
>
> The developer community has approved the proposal to sunset support for Java
> 5 and CDC:
> http://apache-database.10148.n7.nabble.com/VOTE-Sunsetting-support-for-Java-5-and-CDC-td129832.html#a129925
> This issue tracks a number of tasks needed to implement this proposal:
> I) Remove build support for Java 5 and CDC.
> II) Purge user doc references to Java 5, CDC, and the JDBC 4 DataSources.
> III) Remove the JDBC 4 version of the public api from the published javadoc.
> The recently introduced CP2 DataSources would need to migrate to the JDBC 3
> version of the published javadoc. The JDBC 4 versions of the DataSources
> would still exist, but they would be vacuous extensions of their JDBC 3
> counterparts.
> IV) On the wiki, document our expectation that maintenance releases will
> support the same platforms as the original feature release cut from their
> branch.
> V) Decide what to do with the SimpleMobileApp. Probably we want to just
> remove this demo since its purpose is to show how to run Derby on the
> deprecated CDC platform.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
