flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aljoscha Krettek <aljos...@apache.org>
Subject Re: Separation Between Scala and Java TypeExtractor
Date Tue, 06 Jan 2015 13:23:31 GMT
Unfortunately, I don't think so. The Scala reflection is completely
separate from Java reflection. We reuse the PojoTypeInformation,
though.

On Tue, Jan 6, 2015 at 1:16 PM, Stephan Ewen <sewen@apache.org> wrote:
> Okay. My last question was aiming towards whether we can consolidate code
> there and not have two redundant paths (in scala and in java)
>
> On Tue, Jan 6, 2015 at 12:18 PM, Aljoscha Krettek <aljoscha@apache.org>
> wrote:
>
>> Sorry, for the long wait, I had to retry some of my earlier tests.
>>
>>
>>
>> On Tue, Jan 6, 2015 at 11:04 AM, Stephan Ewen <sewen@apache.org> wrote:
>> > Some questions to understand that better:
>> >
>> >  - When can the Scala type extractor not determine the same than the Java
>> > one? What additional cases could the Java Type Extractor find?
>>
>> For a reason I could not discover yet, a Scala Macro cannot see
>> private fields of
>> a Java Class. Thus the Scala TypeExtraction logic would falsely assume that
>> a type is a Pojo while it is in reality not. Those cases, the Java
>> Extractor
>> can handle.
>>
>> >  - How do you distinguish between a Java-created and a Scala-created
>> class?
>>
>> Scala Reflection Type has a method "isJava":
>> tpe.typeSymbol.asClass.isJava == true
>> for Java-defined classes
>>
>> >  - Does it make sense to use the same logic for both, i.e. in Java we
>> give
>> > it the "Class" or "Parameterized Type", in Scala we give it the
>> "ClassTag"
>> > or list of class tags for all generics?
>>
>> What exactly are you suggesting?
>>
>> > Stephan
>> >
>> >
>> > On Tue, Jan 6, 2015 at 11:00 AM, Aljoscha Krettek <aljoscha@apache.org>
>> > wrote:
>> >
>> >> Hi,
>> >> Right now, the Scala Type Extraction logic falls back to using the
>> >> Java TypeExtractor when it encounters a class that was written in Java
>> >> or when it cannot analyse a Scala Type. I did this because the Java
>> >> TypeExtractor might catch some additional cases. The other option
>> >> would be to directly fall back to the GenericTypeInfo when a type is
>> >> defined in Java or when we cannot analyse a type.
>> >>
>> >> What do you think? How should we handle this?
>> >>
>> >> Cheers,
>> >> Aljoscha
>> >>
>>

Mime
View raw message