[
https://issues.apache.org/jira/browse/CALCITE-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14548574#comment-14548574
]
Julian Hyde commented on CALCITE-736:
-------------------------------------
I see your point. However, using ImmutableList in an API (for both parameters
and return types) has considerable benefits to both the API and the caller.
They both know that the list is not changing, therefore is thread-safe, and no
one needs to make a defensive copy; and that it contains no null elements.
(These are the kind of guarantees we take for granted when we pass String
rather than char[] to and from methods. None of us would like to go back to
char[].)
So, I am torn.
> Remove the use of Guava types from public methods and fields
> ------------------------------------------------------------
>
> Key: CALCITE-736
> URL: https://issues.apache.org/jira/browse/CALCITE-736
> Project: Calcite
> Issue Type: Improvement
> Reporter: Santiago M. Mola
> Assignee: Julian Hyde
> Priority: Minor
>
> Guava is involved in major dependency hells in Java, with Hadoop the most
> affected ecosystem.
> Removing Guava types from visible parts of Calcite API will help containing
> damage to backwards compatibility if/when, at some point, shading needs to be
> done.
> This seems quite doable in calcite, since most of its use of Guava in public
> API is ImmutableList. Rewriting it to List and internally doing defensive
> copies with ImmutableList.copyOf (which does not really copy if the input is
> already an ImmutableList) should have a negligible impact.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
