[
https://issues.apache.org/jira/browse/IMPALA-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16699777#comment-16699777
]
ASF subversion and git services commented on IMPALA-7867:
---------------------------------------------------------
Commit 12dc29e5ee1ec03bbc1556eca4539645e2b9bbf1 in impala's branch
refs/heads/master from [~paul-rogers]
[ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=12dc29e ]
IMPALA-7867 (Part 1): Expose List in TreeNode, parser
When using Java collections, a common Java best practice is to expose
the collection interface, but hide the implementation choice. This
pattern allows us to start with a generic implementation (an ArrayList,
say), but evolve to a more specific implementation to achieve certain
goals (a LinkedList or ImmutableList, say.)
For whatever reason, the Impala FE code exposes ArrayList, HashMap and
other implementation choices as variable types and in method signatures.
Also, since Java 7, the preferred way to create an array is
new ArrayList<>()
Replaced older forms:
new ArrayList<foo>() // Pre-Java 7
Lists.newArrayList() // Guava form, pre-Java 7
This ticket cleans up two files, and their dependencies:
* TreeNode (the root of all parser nodes)
* sql-parser.cup (the code which creates the parser nodes)
Many other uses exist, and will be submitted as separate patches to keep
patches small.
In TreeNode, also cleaned up some of the generic expresions, which
caused dependencies to change in order to be more type-safe.
Tests: This is purely a refactoring, no functionality changed. Ran the
FE unit tests to verify no regressions.
Change-Id: Iebab7dccdb4b2fa0b5ca812beab0e8bdba39f539
Reviewed-on: http://gerrit.cloudera.org:8080/11954
Reviewed-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com>
Tested-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com>
> Expose collection interfaces, not implementations
> -------------------------------------------------
>
> Key: IMPALA-7867
> URL: https://issues.apache.org/jira/browse/IMPALA-7867
> Project: IMPALA
> Issue Type: Improvement
> Components: Frontend
> Affects Versions: Impala 3.0
> Reporter: Paul Rogers
> Assignee: Paul Rogers
> Priority: Minor
>
> When using Java collections, a common Java best practice is to expose the
> collection interface, but hide the implementation choice. This pattern allows
> us to start with a generic implementation (an {{ArrayList}}, say), but evolve
> to a more specific implementation to achieve certain goals (a {{LinkedList}}
> or {{ImmutableList}}, say.)
> For whatever reason, the Impala FE code exposes {{ArrayList}}, {{HashMap}}
> and other implementation choices as variable types and in method signatures.
> This ticket tracks a gradual process of revising the declarations and
> signatures to use the interfaces {{List}} instead of the implementation
> {{ArrayList}}.
> Also, the FE code appears to predate Java 7, so that declarations of lists
> tend to be in one of two forms (with or without Guava):
> {code:java}
> foo1 = new ArrayList<Bar>();
> foo2 = Lists.newArrayList();
> {code}
> Since Java 7, the preferred form is:
> {code:java}
> foo = new ArrayList<>();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
