[
https://issues.apache.org/jira/browse/FLINK-15674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021308#comment-17021308
]
Stephan Ewen commented on FLINK-15674:
--------------------------------------
In my (maybe naive) thinking the result / signature of the Macro would still be
the same, just that it calls the TypeExtractor internally. The type extractor
also knows about the Scala types, might even reject case classes and other
generic types if referenced by class only (so that you do not accidentally get
a generic type).
Backwards compatibility would indeed by a thing to carefully consider. Like
when someone used to pass a Case Class by class (and got a generic type) and
would now get a Case Class type.
I am wondering if the generic migration path (deserialize, reserialize) would
automatically work here as long as the class is still the same type.
> Let Java and Scala Type Extraction go through the same stack
> ------------------------------------------------------------
>
> Key: FLINK-15674
> URL: https://issues.apache.org/jira/browse/FLINK-15674
> Project: Flink
> Issue Type: Improvement
> Components: API / DataStream
> Reporter: Stephan Ewen
> Priority: Critical
> Labels: usability
>
> Currently, the Java and Scala Type Extraction stacks are completely different.
> * Java uses the {{TypeExtractor}}
> * Scala uses the type extraction macros.
> As a result, the same class can be extracted as different types in the
> different stacks, which can lead to very confusing results. In particular,
> when you use the TypeExtractor on Scala Classes, you always get a
> {{GenericType}}.
> *Suggestion for New Design*
> There should be one type extraction stack, based on the TypeExtractor.
> * The TypeExtractor should be extensible and load additions through service
> loaders, similar as it currently loads Avro as an extension.
> * The Scala Type Extraction logic should be such an extension.
> * The Scala Marcos would only capture the {{Type}} (as in Java type), meaning
> {{Class}}, or {{ParameterizedType}}, or {{Array}} (etc.) and delegate this to
> the TypeExtractor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)