[
https://issues.apache.org/jira/browse/DERBY-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13658508#comment-13658508
]
Rick Hillegas edited comment on DERBY-6213 at 5/15/13 5:09 PM:
---------------------------------------------------------------
Attaching derby-6213-11-aa-lint3-implStore.diff. This patch generifies the
impl/store packages. I am running tests now.
Generifying RAMTransaction disclosed a mis-factoring of the Store interfaces
which we may want to correct. It appears to have been around since Nat wrote
the original Store code 16 years ago. Nat seems to have been aware of this
because he included this comment in the variables section of RAMTransaction:
// XXX (nat) management of the controllers is still embryonic.
// XXX (nat) would be nice if sort controllers were like conglom
controllers
This mis-factoring may indicate a future brittleness which needs to be fixed. I
don't think the mis-factoring actually causes a bug today. The problem appeared
when I gave RAMTransaction.storeControllers the refined type of
ArrayList<ScanManager>. This is the type which that variable needs in order to
satisfy the loop in closeControllers(). But this caused two problems:
1) In RAMTransaction.openSortScan(), the return type of Sort.openSortScan() was
ScanController rather than ScanManager. That I fixed by changing the type of
Sort.openSortScan() to ScanManager (all of its implementations actually return
ScanManager).
2) In RAMTransaction.openSortRowSource(), the return type of
Sort.openSortRowSource() is also not a ScanManager. The Sort implementations
actually return a ScanManager but I didn't want to just adjust the return type.
I think this needs to be looked at.
Touches the following files:
M java/engine/org/apache/derby/iapi/store/access/conglomerate/Sort.java
M java/engine/org/apache/derby/impl/store/access/sort/MergeScan.java
M java/engine/org/apache/derby/impl/store/access/sort/MergeSort.java
M java/engine/org/apache/derby/impl/store/access/sort/MergeInserter.java
M
java/engine/org/apache/derby/impl/store/access/sort/MergeScanRowSource.java
M java/engine/org/apache/derby/impl/store/access/PropertyConglomerate.java
M java/engine/org/apache/derby/impl/store/access/RAMTransaction.java
M java/engine/org/apache/derby/impl/store/access/RAMAccessManager.java
M java/engine/org/apache/derby/impl/store/raw/xact/Xact.java
M
java/engine/org/apache/derby/impl/store/raw/xact/TransactionMapFactory.java
M
java/engine/org/apache/derby/impl/store/raw/xact/ConcurrentTransactionMapFactory.java
M
java/engine/org/apache/derby/impl/store/raw/xact/XactXAResourceManager.java
M java/engine/org/apache/derby/impl/store/raw/xact/TransactionTable.java
M java/engine/org/apache/derby/impl/store/raw/log/LogAccessFile.java
M java/engine/org/apache/derby/impl/store/raw/log/LogToFile.java
M java/engine/org/apache/derby/impl/store/raw/RawStore.java
M java/engine/org/apache/derby/impl/store/raw/data/MemByteHolder.java
M
java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactory.java
M
java/engine/org/apache/derby/impl/store/raw/data/StreamFileContainer.java
M
java/engine/org/apache/derby/impl/store/raw/data/EncryptOrDecryptData.java
M java/engine/org/apache/derby/impl/store/raw/data/RFResource.java
M java/engine/org/apache/derby/impl/store/raw/data/RAFContainer.java
M
java/engine/org/apache/derby/impl/store/replication/net/ReplicationMessageTransmit.java
M
java/engine/org/apache/derby/impl/store/replication/net/ReplicationMessageReceive.java
M
java/engine/org/apache/derby/impl/store/replication/buffer/ReplicationLogBuffer.java
M java/engine/org/apache/derby/impl/store/build.xml
was (Author: rhillegas):
Attaching derby-6213-11-aa-lint3-implStore.diff. This patch generifies the
impl/store packages. I am running tests now.
Generifying RAMTransaction disclosed a mis-factoring of the Store interfaces
which we may want to correct. It appears to have been around since Nat wrote
the original Store code 16 years ago. Nat seems to have been aware of this
because he included this comment in the variables section of RAMTransaction:
// XXX (nat) management of the controllers is still embryonic.
// XXX (nat) would be nice if sort controllers were like conglom
controllers
This mis-factoring may indicate a future brittleness which needs to be fixed. I
don't think the mis-factoring actually causes a bug today. The problem appeared
when I gave RAMTransaction.storeControllers the refined type of
ArrayList<ScanManager>. This is the type which that variable needs in order to
satisfy the loop in closeControllers(). But this caused two problems:
1) In RAMTransaction.openSortScan(), the return type of Sort.openSortScan() was
ScanController rather than ScanManager. That I fixed by changing the type of
Sort.openSortScan() to ScanManager (all of its implementations actually return
SortManager).
2) In RAMTransaction.openSortRowSource(), the return type of
Sort.openSortRowSource() is also not a ScanManager. The Sort implementations
actually return a ScanManager but I didn't want to just adjust the return type.
I think this needs to be looked at.
Touches the following files:
M java/engine/org/apache/derby/iapi/store/access/conglomerate/Sort.java
M java/engine/org/apache/derby/impl/store/access/sort/MergeScan.java
M java/engine/org/apache/derby/impl/store/access/sort/MergeSort.java
M java/engine/org/apache/derby/impl/store/access/sort/MergeInserter.java
M
java/engine/org/apache/derby/impl/store/access/sort/MergeScanRowSource.java
M java/engine/org/apache/derby/impl/store/access/PropertyConglomerate.java
M java/engine/org/apache/derby/impl/store/access/RAMTransaction.java
M java/engine/org/apache/derby/impl/store/access/RAMAccessManager.java
M java/engine/org/apache/derby/impl/store/raw/xact/Xact.java
M
java/engine/org/apache/derby/impl/store/raw/xact/TransactionMapFactory.java
M
java/engine/org/apache/derby/impl/store/raw/xact/ConcurrentTransactionMapFactory.java
M
java/engine/org/apache/derby/impl/store/raw/xact/XactXAResourceManager.java
M java/engine/org/apache/derby/impl/store/raw/xact/TransactionTable.java
M java/engine/org/apache/derby/impl/store/raw/log/LogAccessFile.java
M java/engine/org/apache/derby/impl/store/raw/log/LogToFile.java
M java/engine/org/apache/derby/impl/store/raw/RawStore.java
M java/engine/org/apache/derby/impl/store/raw/data/MemByteHolder.java
M
java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactory.java
M
java/engine/org/apache/derby/impl/store/raw/data/StreamFileContainer.java
M
java/engine/org/apache/derby/impl/store/raw/data/EncryptOrDecryptData.java
M java/engine/org/apache/derby/impl/store/raw/data/RFResource.java
M java/engine/org/apache/derby/impl/store/raw/data/RAFContainer.java
M
java/engine/org/apache/derby/impl/store/replication/net/ReplicationMessageTransmit.java
M
java/engine/org/apache/derby/impl/store/replication/net/ReplicationMessageReceive.java
M
java/engine/org/apache/derby/impl/store/replication/buffer/ReplicationLogBuffer.java
M java/engine/org/apache/derby/impl/store/build.xml
> 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, 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
