[
https://issues.apache.org/jira/browse/DERBY-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-6075:
--------------------------------------
Attachment: d6075-5a-ordering.diff
Attaching d6075-5a-ordering.diff, which makes the classes RowOrderingImpl and
ColumnOrdering use java.util.ArrayList instead of java.util.Vector to store
ordering information internally. The vectors are only accessed during
compilation, which is single-threaded so the synchronization is not needed.
I took the opportunity to do the following cleanup in those two classes:
- Replaced checks for size() == 0 with isEmpty()
- Replaced the body of ColumnOrdering.hasTable() with a simple call to
List.contains()
- Removed redundant size() check at the beginning of
ColumnOrdering.hasAnyOtherTable()
- Replaced allocation of fresh Integer objects for table numbers and column
numbers with calls to ReuseFactory. Since table and column numbers tend to be
small, they can almost always be taken from ReuseFactory's cache. (Eventually,
we'll probably replace ReuseFactory.getInteger(int) with Integer.valueOf(int)
and use the JVM's cache, but we need to make Java 5 the minimum platform before
we can do that.)
All regression tests ran cleanly with the patch.
> Use modern collections in impl/sql/compile
> ------------------------------------------
>
> Key: DERBY-6075
> URL: https://issues.apache.org/jira/browse/DERBY-6075
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.10.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: d6075-1a-CollectNodesVisitor.diff,
> d6075-2a-bindExpression.diff, d6075-3a-javadoc.diff,
> d6075-4a-parameterList.diff, d6075-5a-ordering.diff
>
>
> The code in the org.apache.derby.impl.sql.compile package predates the Java
> Collections Framework and uses old-style collections like java.util.Vector
> and java.util.Hashtable. Since the old-style collection classes are used in
> many method signatures, it's difficult to use modern collection classes when
> adding new code.
> I suggest we switch to using interfaces (like java.util.List and
> java.util.Map) instead of specific classes in the signatures, so that we have
> more flexibility in choosing the right collection class for the job.
> Only changing the signatures would allow us to continue using Vector and
> Hashtable, since they implement the interfaces. However, I think it would be
> good to switch to ArrayList and HashMap in a second step. The instances in
> impl/sql/compile are not shared between threads, so we don't need the
> synchronization provided by the old-style classes. Switching to
> unsynchronized classes may make compilation slightly faster.
--
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
