[
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-14a-dead-syntax.diff
There are also some uses of Vector in sqlgrammar.jj, which generates classes
that live in the impl/sql/compile package. Those vectors are private to the
thread that's parsing the SQL statement, as far as I can tell, so it should be
safe to replace them with ArrayLists.
Before doing that, I'm attaching a cleanup patch (d6075-14a-dead-syntax.diff)
which removes unneeded import statements from sqlgrammar.jj and removes some
dead code that uses vectors.
The removed dead code seems to be there in order to support syntax for
declaring columns nullable explicitly. There is however no such syntax in Derby
currently (you can only declare them nullable implicitly by skipping the NOT
NULL constraint), so the following fields and the code that accesses them are
removed:
- explicitNotNull (a boolean)
- explicitNull (a boolean)
- explicitlyNullableColumnsList (a Vector)
The purpose of the fields is to check whether a column is declared explicitly
nullable and not nullable at the same time, and raise an error if so happens.
Since there is no way to declare a column explicitly nullable (evidence: there
is no code that sets explicitlyNull to true, and there is no code that adds
elements to explicitlyNullableColumnsList), that's an impossible situation.
In addition to removing the dead code from sqlgrammar.jj, the patch removes the
unused SQLState and the corresponding error message, including translations.
All 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-10a-aggregate-vectors.diff,
> d6075-11a-remaining-vectors.diff, d6075-12a-stack.diff,
> d6075-13a-unused-properties.diff, d6075-14a-dead-syntax.diff,
> d6075-1a-CollectNodesVisitor.diff, d6075-2a-bindExpression.diff,
> d6075-3a-javadoc.diff, d6075-4a-parameterList.diff, d6075-5a-ordering.diff,
> d6075-6a-DMLModStatementNode.diff, d6075-7a-more-signatures.diff,
> d6075-8a-local-hashtables.diff, d6075-9a-hashtable-fields.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
