Separation Between Scala and Java TypeExtractor

[Aljoscha Krettek-2]

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

[Stephan Ewen]

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?

 - How do you distinguish between a Java-created and a Scala-created class?

 - 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?

Stephan


On Tue, Jan 6, 2015 at 11:00 AM, Aljoscha Krettek <[hidden email]>
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
>

[Aljoscha Krettek-2]

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 <[hidden email]> 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 <[hidden email]>
> 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
>>

[Stephan Ewen]

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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
> > 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
> >>
>

[Aljoscha Krettek-2]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
>> > 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
>> >>
>>