[
https://issues.apache.org/jira/browse/CALCITE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418781#comment-17418781
]
Jacques Nadeau commented on CALCITE-4787:
-----------------------------------------
> Do we have to change a huge number of Calcite files
All rules would have to change so it would be a decent number of files. That
being said, I believe it could be done piecemeal (where some rules have changed
and some haven't yet) to make reviews less painful. Note, I haven't actually
tried to do a coexistence pattern but I believe it is possible.
> Do we require dependent projects to change their code.
Only when they are using RelRule.Config.as or RelRule.Config.EMPTY. There are
examples in the wild but they seem relatively scarce. I think this in large
part due to the fact that rules are now configurable (so everyone doesn't have
to reimplemnt). Advanced users may have entirely new rules. For example, a
GitHub search for Hive shows the following two usages:
[https://github.com/apache/hive/search?q=RelRule+EMPTY.
|https://github.com/apache/hive/search?q=RelRule+EMPTY]
> If a dependent project is using a different version of Immutables, what will
>be the impact?
Short answer: No new transitive dependencies, no conflicts.
Longer answer:
There are two components to immutables: annotation processor and annotations.
The annotation processor is only used during Calcite compilation so version
conflicts there don't exist. The annotations themselves are declared as
provided so they are not inherited by downstream projects. They are SOURCE
retained so if they we directly declare class annotation arguments such as
ImplementationVisibility, that will trigger a compilation warning for a user
downstream if they don't also source a version of annotations that includes
that referenced class. As such, we should avoid the use of those kinds of
declarations (direct referencing immutables classes). In the cases where we
want to use this functionality, we should do so using a pattern similar to what
I did with CalciteImmutable (where it is declared as an annotation of an
annotation).
The other situation is if the downstream user wants to use Immutables to build
their own rule configurations. In that case, they would only be able to benefit
from the declared annotations on the base classes if they used a version of
immutables that has that annotation. Since the only annotation we're using is
@Value.Default, I believe that existed for some time. If they used a version of
immutables that didn't have that, they would have to declare defaults in their
own way. So this shouldn't stop them from doing anything.
> Evaluate use of Immutables instead of ImmutableBeans
> ----------------------------------------------------
>
> Key: CALCITE-4787
> URL: https://issues.apache.org/jira/browse/CALCITE-4787
> Project: Calcite
> Issue Type: Improvement
> Reporter: Jacques Nadeau
> Assignee: Jacques Nadeau
> Priority: Major
> Labels: pull-request-available
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> In the creation of CALCITE-3328, [Immutables|https://immutables.github.io/]
> was discussed as an alternative to a custom implementation. This ticket is to
> evaluate the impact to the codebase of changing. Ideally, introduction of
> immutables would both add flexibility and reduce the amount of code
> associated with these classes.
> Immutables works via annotation processor which means that it is should be
> relatively seamless to build systems and IDEs.
> The switch would also make it easier to work with these objects types in the
> context of aot compilation tools like GraalVM.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
