db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-6213) Deprecate support for Java 5 and CDC
Date Wed, 15 May 2013 16:27:15 GMT

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

Rick Hillegas updated DERBY-6213:
---------------------------------

    Attachment: derby-6213-11-aa-lint3-implStore.diff

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 SortController
rather than SortManager. That I fixed by changing the type of Sort.openSortScan() to SortManager
(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

Mime
View raw message