Eclipse Problems

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Eclipse Problems

Matthias J. Sax-2
Hi,

someone put this question on SO:
https://stackoverflow.com/questions/36824684/eclipse-imported-maven-project-cannot-resolve-symbols-in-other-imported-maven-pr

I can only confirm that Eclipse does not build Flink anymore. It shows
"103 Errors" in my case. Not sure how many Eclipse users are still out
there and if this should get fixed or not.

If not, the website should get updated, saying only Intellij is
supported for Flink development.

What do you think about this?


-Matthias


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Problems

Ufuk Celebi-2
On Mon, Apr 25, 2016 at 12:14 AM, Matthias J. Sax <[hidden email]> wrote:
> What do you think about this?

Hey Matthias!

Thanks for bringing this up.

I think it is very desirable to keep support for Eclipse. It's quite a
high barrier for new contributors to enforce a specific IDE (although
IntelliJ is gaining quite the user base I think :P).

Do you have time to look into this?

– Ufuk
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Problems

Robert Metzger
It seems that the user resolved the issue on SO, right?

On Mon, Apr 25, 2016 at 11:31 AM, Ufuk Celebi <[hidden email]> wrote:

> On Mon, Apr 25, 2016 at 12:14 AM, Matthias J. Sax <[hidden email]>
> wrote:
> > What do you think about this?
>
> Hey Matthias!
>
> Thanks for bringing this up.
>
> I think it is very desirable to keep support for Eclipse. It's quite a
> high barrier for new contributors to enforce a specific IDE (although
> IntelliJ is gaining quite the user base I think :P).
>
> Do you have time to look into this?
>
> – Ufuk
>
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Problems

Matthias J. Sax-2
I can confirm that the SO answer works.

I will add a note to the Eclipse setup guide at the web site.

-Matthias


On 04/25/2016 11:33 AM, Robert Metzger wrote:

> It seems that the user resolved the issue on SO, right?
>
> On Mon, Apr 25, 2016 at 11:31 AM, Ufuk Celebi <[hidden email]> wrote:
>
>> On Mon, Apr 25, 2016 at 12:14 AM, Matthias J. Sax <[hidden email]>
>> wrote:
>>> What do you think about this?
>>
>> Hey Matthias!
>>
>> Thanks for bringing this up.
>>
>> I think it is very desirable to keep support for Eclipse. It's quite a
>> high barrier for new contributors to enforce a specific IDE (although
>> IntelliJ is gaining quite the user base I think :P).
>>
>> Do you have time to look into this?
>>
>> – Ufuk
>>
>


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Problems

Robert Metzger
Cool, thank you for working on this!

On Mon, Apr 25, 2016 at 1:37 PM, Matthias J. Sax <[hidden email]> wrote:

> I can confirm that the SO answer works.
>
> I will add a note to the Eclipse setup guide at the web site.
>
> -Matthias
>
>
> On 04/25/2016 11:33 AM, Robert Metzger wrote:
> > It seems that the user resolved the issue on SO, right?
> >
> > On Mon, Apr 25, 2016 at 11:31 AM, Ufuk Celebi <[hidden email]> wrote:
> >
> >> On Mon, Apr 25, 2016 at 12:14 AM, Matthias J. Sax <[hidden email]>
> >> wrote:
> >>> What do you think about this?
> >>
> >> Hey Matthias!
> >>
> >> Thanks for bringing this up.
> >>
> >> I think it is very desirable to keep support for Eclipse. It's quite a
> >> high barrier for new contributors to enforce a specific IDE (although
> >> IntelliJ is gaining quite the user base I think :P).
> >>
> >> Do you have time to look into this?
> >>
> >> – Ufuk
> >>
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Problems

Matthias J. Sax-2
Even if the fix works, I still have two issues in my Eclipse build...

In

flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala

Eclipse cannot infer the integer type. It could be fixed if you make the
type explicit (as this is only a test, it might be nice to fix this --
let me know if I can push this or not)

> diff --git a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> index c2e13fe..f9ce3b8 100644
> --- a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> +++ b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> @@ -29,7 +29,7 @@ private[extensions] abstract class AcceptPFTestBase extends TestLogger with JUni
>  
>    private val env = ExecutionEnvironment.getExecutionEnvironment
>  
> -  protected val tuples = env.fromElements(1 -> "hello", 2 -> "world")
> +  protected val tuples = env.fromElements(new Integer(1) -> "hello", new Integer(2) -> "world")
>    protected val caseObjects = env.fromElements(KeyValuePair(1, "hello"), KeyValuePair(2, "world"))
>  
>    protected val groupedTuples = tuples.groupBy(_._1)
Furthermore, in

flink-java/src/test/java/org/apache/flink/api/java/io/FromElementsTest.java

> @Test
> public void fromElementsWithBaseTypeTest1() {
> ExecutionEnvironment executionEnvironment = ExecutionEnvironment.getExecutionEnvironment();
> executionEnvironment.fromElements(ParentType.class, new SubType(1, "Java"), new ParentType(1, "hello"));
> }

and in

flink-streaming-java/src/test/java/org/apache/flink/streaming/api/StreamExecutionEnvironmentTest.java

> @Test
> public void fromElementsWithBaseTypeTest1() {
> StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
> env.fromElements(ParentClass.class, new SubClass(1, "Java"), new ParentClass(1, "hello"));
> }

In both cases, I get the error:

  The method .fromElements(Object[]) is ambiguous

No clue how to fix this, and why Eclipse does not bind to
.fromElements(Class<X>, X). Any ideas?

I also digger a little bit and for both test-classes there is a second
test method called "fromElementsWithBaseTypeTest2". If I understand this
test correctly, it also tries to bind to .fromElements(Class<X>, X), but
this does not happen and .fromElemenst(Object[]) is called. Even if
there is still an exception, I got the impression that this test does
not what the intention was.

If might be good to change fromElementsWithBaseTypeTest2 to

> env.fromElements(new SubClass(1, "Java"), new ParentClass(1, "hello"));

(ie, remove the first Class parameter). Any comments on this?

-Matthias



On 04/25/2016 01:42 PM, Robert Metzger wrote:

> Cool, thank you for working on this!
>
> On Mon, Apr 25, 2016 at 1:37 PM, Matthias J. Sax <[hidden email]> wrote:
>
>> I can confirm that the SO answer works.
>>
>> I will add a note to the Eclipse setup guide at the web site.
>>
>> -Matthias
>>
>>
>> On 04/25/2016 11:33 AM, Robert Metzger wrote:
>>> It seems that the user resolved the issue on SO, right?
>>>
>>> On Mon, Apr 25, 2016 at 11:31 AM, Ufuk Celebi <[hidden email]> wrote:
>>>
>>>> On Mon, Apr 25, 2016 at 12:14 AM, Matthias J. Sax <[hidden email]>
>>>> wrote:
>>>>> What do you think about this?
>>>>
>>>> Hey Matthias!
>>>>
>>>> Thanks for bringing this up.
>>>>
>>>> I think it is very desirable to keep support for Eclipse. It's quite a
>>>> high barrier for new contributors to enforce a specific IDE (although
>>>> IntelliJ is gaining quite the user base I think :P).
>>>>
>>>> Do you have time to look into this?
>>>>
>>>> – Ufuk
>>>>
>>>
>>
>>
>


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Problems

Till Rohrmann
Thanks for looking into this problem Mathias. I think the Scala test should
be fixed as you've proposed.

Concerning the StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2,
I think it shouldn't be changed. The reason is that the class defines the
common base class of the elements. And the test makes sure that the
fromElements call fails if you provide instances which are not of the
specified type or a subclass of it. Thus, we should find another way to
make it work with Eclipse.

Cheers,
Till

On Tue, Apr 26, 2016 at 9:41 PM, Matthias J. Sax <[hidden email]> wrote:

> Even if the fix works, I still have two issues in my Eclipse build...
>
> In
>
>
> flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>
> Eclipse cannot infer the integer type. It could be fixed if you make the
> type explicit (as this is only a test, it might be nice to fix this --
> let me know if I can push this or not)
>
> > diff --git
> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> > index c2e13fe..f9ce3b8 100644
> > ---
> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> > +++
> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> > @@ -29,7 +29,7 @@ private[extensions] abstract class AcceptPFTestBase
> extends TestLogger with JUni
> >
> >    private val env = ExecutionEnvironment.getExecutionEnvironment
> >
> > -  protected val tuples = env.fromElements(1 -> "hello", 2 -> "world")
> > +  protected val tuples = env.fromElements(new Integer(1) -> "hello",
> new Integer(2) -> "world")
> >    protected val caseObjects = env.fromElements(KeyValuePair(1,
> "hello"), KeyValuePair(2, "world"))
> >
> >    protected val groupedTuples = tuples.groupBy(_._1)
>
> Furthermore, in
>
> flink-java/src/test/java/org/apache/flink/api/java/io/FromElementsTest.java
>
> > @Test
> > public void fromElementsWithBaseTypeTest1() {
> >       ExecutionEnvironment executionEnvironment =
> ExecutionEnvironment.getExecutionEnvironment();
> >       executionEnvironment.fromElements(ParentType.class, new SubType(1,
> "Java"), new ParentType(1, "hello"));
> > }
>
> and in
>
>
> flink-streaming-java/src/test/java/org/apache/flink/streaming/api/StreamExecutionEnvironmentTest.java
>
> > @Test
> > public void fromElementsWithBaseTypeTest1() {
> >       StreamExecutionEnvironment env =
> StreamExecutionEnvironment.getExecutionEnvironment();
> >       env.fromElements(ParentClass.class, new SubClass(1, "Java"), new
> ParentClass(1, "hello"));
> > }
>
> In both cases, I get the error:
>
>   The method .fromElements(Object[]) is ambiguous
>
> No clue how to fix this, and why Eclipse does not bind to
> .fromElements(Class<X>, X). Any ideas?
>
> I also digger a little bit and for both test-classes there is a second
> test method called "fromElementsWithBaseTypeTest2". If I understand this
> test correctly, it also tries to bind to .fromElements(Class<X>, X), but
> this does not happen and .fromElemenst(Object[]) is called. Even if
> there is still an exception, I got the impression that this test does
> not what the intention was.
>
> If might be good to change fromElementsWithBaseTypeTest2 to
>
> > env.fromElements(new SubClass(1, "Java"), new ParentClass(1, "hello"));
>
> (ie, remove the first Class parameter). Any comments on this?
>
> -Matthias
>
>
>
> On 04/25/2016 01:42 PM, Robert Metzger wrote:
> > Cool, thank you for working on this!
> >
> > On Mon, Apr 25, 2016 at 1:37 PM, Matthias J. Sax <[hidden email]>
> wrote:
> >
> >> I can confirm that the SO answer works.
> >>
> >> I will add a note to the Eclipse setup guide at the web site.
> >>
> >> -Matthias
> >>
> >>
> >> On 04/25/2016 11:33 AM, Robert Metzger wrote:
> >>> It seems that the user resolved the issue on SO, right?
> >>>
> >>> On Mon, Apr 25, 2016 at 11:31 AM, Ufuk Celebi <[hidden email]> wrote:
> >>>
> >>>> On Mon, Apr 25, 2016 at 12:14 AM, Matthias J. Sax <[hidden email]>
> >>>> wrote:
> >>>>> What do you think about this?
> >>>>
> >>>> Hey Matthias!
> >>>>
> >>>> Thanks for bringing this up.
> >>>>
> >>>> I think it is very desirable to keep support for Eclipse. It's quite a
> >>>> high barrier for new contributors to enforce a specific IDE (although
> >>>> IntelliJ is gaining quite the user base I think :P).
> >>>>
> >>>> Do you have time to look into this?
> >>>>
> >>>> – Ufuk
> >>>>
> >>>
> >>
> >>
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Problems

Matthias J. Sax-2
Hi Till,

but StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2 does not
test was you describe -- even if it is intended to test it.

It would test your describe scenario, if fromElements(Class<X>, X...)
would be called, But this call is not possible because X is defined a
type Subclass and thus the provided object of Parentclass cannot be
handed over as type X. Therefore, fromElements(Object...) is called: of
course, this fails too, because now the type is derived as
Class<Subclass> (and not Subclass) and neither Subclass nor Parentclass
inherit from Class<Subclass>.

The scenario you describe will never work -- if you remove the overload
fromElements(Object...) the code would not even compile as the compiler
can figure out from the generics that the call
fromElments(Subclass.class, new Parentclass()) is invalid.

It is only possible to hand in "reverse inheritance types" for
fromElemenst(Object...). In this case, the first given Object defines
the type. Thus, if you call fromElements(new Subclass(), new
Parentclass()), the call will fail, as Parentclass is no subtype of
Subtype -- the call fromElements(new Parentclass() new Subclass()) would
succeed.

Makes sense?

Still no idea how to make it compile in Eclipse...

-Matthias

On 04/27/2016 10:21 AM, Till Rohrmann wrote:

> Thanks for looking into this problem Mathias. I think the Scala test should
> be fixed as you've proposed.
>
> Concerning the StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2,
> I think it shouldn't be changed. The reason is that the class defines the
> common base class of the elements. And the test makes sure that the
> fromElements call fails if you provide instances which are not of the
> specified type or a subclass of it. Thus, we should find another way to
> make it work with Eclipse.
>
> Cheers,
> Till
>
> On Tue, Apr 26, 2016 at 9:41 PM, Matthias J. Sax <[hidden email]> wrote:
>
>> Even if the fix works, I still have two issues in my Eclipse build...
>>
>> In
>>
>>
>> flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>
>> Eclipse cannot infer the integer type. It could be fixed if you make the
>> type explicit (as this is only a test, it might be nice to fix this --
>> let me know if I can push this or not)
>>
>>> diff --git
>> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>> index c2e13fe..f9ce3b8 100644
>>> ---
>> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>> +++
>> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>> @@ -29,7 +29,7 @@ private[extensions] abstract class AcceptPFTestBase
>> extends TestLogger with JUni
>>>
>>>    private val env = ExecutionEnvironment.getExecutionEnvironment
>>>
>>> -  protected val tuples = env.fromElements(1 -> "hello", 2 -> "world")
>>> +  protected val tuples = env.fromElements(new Integer(1) -> "hello",
>> new Integer(2) -> "world")
>>>    protected val caseObjects = env.fromElements(KeyValuePair(1,
>> "hello"), KeyValuePair(2, "world"))
>>>
>>>    protected val groupedTuples = tuples.groupBy(_._1)
>>
>> Furthermore, in
>>
>> flink-java/src/test/java/org/apache/flink/api/java/io/FromElementsTest.java
>>
>>> @Test
>>> public void fromElementsWithBaseTypeTest1() {
>>>       ExecutionEnvironment executionEnvironment =
>> ExecutionEnvironment.getExecutionEnvironment();
>>>       executionEnvironment.fromElements(ParentType.class, new SubType(1,
>> "Java"), new ParentType(1, "hello"));
>>> }
>>
>> and in
>>
>>
>> flink-streaming-java/src/test/java/org/apache/flink/streaming/api/StreamExecutionEnvironmentTest.java
>>
>>> @Test
>>> public void fromElementsWithBaseTypeTest1() {
>>>       StreamExecutionEnvironment env =
>> StreamExecutionEnvironment.getExecutionEnvironment();
>>>       env.fromElements(ParentClass.class, new SubClass(1, "Java"), new
>> ParentClass(1, "hello"));
>>> }
>>
>> In both cases, I get the error:
>>
>>   The method .fromElements(Object[]) is ambiguous
>>
>> No clue how to fix this, and why Eclipse does not bind to
>> .fromElements(Class<X>, X). Any ideas?
>>
>> I also digger a little bit and for both test-classes there is a second
>> test method called "fromElementsWithBaseTypeTest2". If I understand this
>> test correctly, it also tries to bind to .fromElements(Class<X>, X), but
>> this does not happen and .fromElemenst(Object[]) is called. Even if
>> there is still an exception, I got the impression that this test does
>> not what the intention was.
>>
>> If might be good to change fromElementsWithBaseTypeTest2 to
>>
>>> env.fromElements(new SubClass(1, "Java"), new ParentClass(1, "hello"));
>>
>> (ie, remove the first Class parameter). Any comments on this?
>>
>> -Matthias
>>
>>
>>
>> On 04/25/2016 01:42 PM, Robert Metzger wrote:
>>> Cool, thank you for working on this!
>>>
>>> On Mon, Apr 25, 2016 at 1:37 PM, Matthias J. Sax <[hidden email]>
>> wrote:
>>>
>>>> I can confirm that the SO answer works.
>>>>
>>>> I will add a note to the Eclipse setup guide at the web site.
>>>>
>>>> -Matthias
>>>>
>>>>
>>>> On 04/25/2016 11:33 AM, Robert Metzger wrote:
>>>>> It seems that the user resolved the issue on SO, right?
>>>>>
>>>>> On Mon, Apr 25, 2016 at 11:31 AM, Ufuk Celebi <[hidden email]> wrote:
>>>>>
>>>>>> On Mon, Apr 25, 2016 at 12:14 AM, Matthias J. Sax <[hidden email]>
>>>>>> wrote:
>>>>>>> What do you think about this?
>>>>>>
>>>>>> Hey Matthias!
>>>>>>
>>>>>> Thanks for bringing this up.
>>>>>>
>>>>>> I think it is very desirable to keep support for Eclipse. It's quite a
>>>>>> high barrier for new contributors to enforce a specific IDE (although
>>>>>> IntelliJ is gaining quite the user base I think :P).
>>>>>>
>>>>>> Do you have time to look into this?
>>>>>>
>>>>>> – Ufuk
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Problems

Till Rohrmann
You’re completely right Mathias. The compiler shouldn’t allow something
like env.fromElements(SubClass.class, new ParentClass()) if it weren’t for
the overloaded method. Thus, the test case is somewhat bogus.

I’m actually wondering why the initial problem
https://issues.apache.org/jira/browse/FLINK-3444 was solved this way. I
think it would be better to automatically infer the common super type of
all provided elements. Otherwise, you run into problems you’ve found out
about.

Consequently, I think it is fine if you remove the fromElementsWithBaseType2
test case.

Cheers,
Till


On Wed, Apr 27, 2016 at 1:22 PM, Matthias J. Sax <[hidden email]> wrote:

> Hi Till,
>
> but StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2 does not
> test was you describe -- even if it is intended to test it.
>
> It would test your describe scenario, if fromElements(Class<X>, X...)
> would be called, But this call is not possible because X is defined a
> type Subclass and thus the provided object of Parentclass cannot be
> handed over as type X. Therefore, fromElements(Object...) is called: of
> course, this fails too, because now the type is derived as
> Class<Subclass> (and not Subclass) and neither Subclass nor Parentclass
> inherit from Class<Subclass>.
>
> The scenario you describe will never work -- if you remove the overload
> fromElements(Object...) the code would not even compile as the compiler
> can figure out from the generics that the call
> fromElments(Subclass.class, new Parentclass()) is invalid.
>
> It is only possible to hand in "reverse inheritance types" for
> fromElemenst(Object...). In this case, the first given Object defines
> the type. Thus, if you call fromElements(new Subclass(), new
> Parentclass()), the call will fail, as Parentclass is no subtype of
> Subtype -- the call fromElements(new Parentclass() new Subclass()) would
> succeed.
>
> Makes sense?
>
> Still no idea how to make it compile in Eclipse...
>
> -Matthias
>
> On 04/27/2016 10:21 AM, Till Rohrmann wrote:
> > Thanks for looking into this problem Mathias. I think the Scala test
> should
> > be fixed as you've proposed.
> >
> > Concerning the
> StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2,
> > I think it shouldn't be changed. The reason is that the class defines the
> > common base class of the elements. And the test makes sure that the
> > fromElements call fails if you provide instances which are not of the
> > specified type or a subclass of it. Thus, we should find another way to
> > make it work with Eclipse.
> >
> > Cheers,
> > Till
> >
> > On Tue, Apr 26, 2016 at 9:41 PM, Matthias J. Sax <[hidden email]>
> wrote:
> >
> >> Even if the fix works, I still have two issues in my Eclipse build...
> >>
> >> In
> >>
> >>
> >>
> flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>
> >> Eclipse cannot infer the integer type. It could be fixed if you make the
> >> type explicit (as this is only a test, it might be nice to fix this --
> >> let me know if I can push this or not)
> >>
> >>> diff --git
> >>
> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>
> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>> index c2e13fe..f9ce3b8 100644
> >>> ---
> >>
> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>> +++
> >>
> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>> @@ -29,7 +29,7 @@ private[extensions] abstract class AcceptPFTestBase
> >> extends TestLogger with JUni
> >>>
> >>>    private val env = ExecutionEnvironment.getExecutionEnvironment
> >>>
> >>> -  protected val tuples = env.fromElements(1 -> "hello", 2 -> "world")
> >>> +  protected val tuples = env.fromElements(new Integer(1) -> "hello",
> >> new Integer(2) -> "world")
> >>>    protected val caseObjects = env.fromElements(KeyValuePair(1,
> >> "hello"), KeyValuePair(2, "world"))
> >>>
> >>>    protected val groupedTuples = tuples.groupBy(_._1)
> >>
> >> Furthermore, in
> >>
> >>
> flink-java/src/test/java/org/apache/flink/api/java/io/FromElementsTest.java
> >>
> >>> @Test
> >>> public void fromElementsWithBaseTypeTest1() {
> >>>       ExecutionEnvironment executionEnvironment =
> >> ExecutionEnvironment.getExecutionEnvironment();
> >>>       executionEnvironment.fromElements(ParentType.class, new
> SubType(1,
> >> "Java"), new ParentType(1, "hello"));
> >>> }
> >>
> >> and in
> >>
> >>
> >>
> flink-streaming-java/src/test/java/org/apache/flink/streaming/api/StreamExecutionEnvironmentTest.java
> >>
> >>> @Test
> >>> public void fromElementsWithBaseTypeTest1() {
> >>>       StreamExecutionEnvironment env =
> >> StreamExecutionEnvironment.getExecutionEnvironment();
> >>>       env.fromElements(ParentClass.class, new SubClass(1, "Java"), new
> >> ParentClass(1, "hello"));
> >>> }
> >>
> >> In both cases, I get the error:
> >>
> >>   The method .fromElements(Object[]) is ambiguous
> >>
> >> No clue how to fix this, and why Eclipse does not bind to
> >> .fromElements(Class<X>, X). Any ideas?
> >>
> >> I also digger a little bit and for both test-classes there is a second
> >> test method called "fromElementsWithBaseTypeTest2". If I understand this
> >> test correctly, it also tries to bind to .fromElements(Class<X>, X), but
> >> this does not happen and .fromElemenst(Object[]) is called. Even if
> >> there is still an exception, I got the impression that this test does
> >> not what the intention was.
> >>
> >> If might be good to change fromElementsWithBaseTypeTest2 to
> >>
> >>> env.fromElements(new SubClass(1, "Java"), new ParentClass(1, "hello"));
> >>
> >> (ie, remove the first Class parameter). Any comments on this?
> >>
> >> -Matthias
> >>
> >>
> >>
> >> On 04/25/2016 01:42 PM, Robert Metzger wrote:
> >>> Cool, thank you for working on this!
> >>>
> >>> On Mon, Apr 25, 2016 at 1:37 PM, Matthias J. Sax <[hidden email]>
> >> wrote:
> >>>
> >>>> I can confirm that the SO answer works.
> >>>>
> >>>> I will add a note to the Eclipse setup guide at the web site.
> >>>>
> >>>> -Matthias
> >>>>
> >>>>
> >>>> On 04/25/2016 11:33 AM, Robert Metzger wrote:
> >>>>> It seems that the user resolved the issue on SO, right?
> >>>>>
> >>>>> On Mon, Apr 25, 2016 at 11:31 AM, Ufuk Celebi <[hidden email]>
> wrote:
> >>>>>
> >>>>>> On Mon, Apr 25, 2016 at 12:14 AM, Matthias J. Sax <[hidden email]
> >
> >>>>>> wrote:
> >>>>>>> What do you think about this?
> >>>>>>
> >>>>>> Hey Matthias!
> >>>>>>
> >>>>>> Thanks for bringing this up.
> >>>>>>
> >>>>>> I think it is very desirable to keep support for Eclipse. It's
> quite a
> >>>>>> high barrier for new contributors to enforce a specific IDE
> (although
> >>>>>> IntelliJ is gaining quite the user base I think :P).
> >>>>>>
> >>>>>> Do you have time to look into this?
> >>>>>>
> >>>>>> – Ufuk
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Problems

Matthias J. Sax-2
I guess, removing .fromElements(Object..) would fix the problem. Not
sure so, if we can remove the method due to API stability...

I don't see any other good solution (even if the current implementation
gives a nice behavior by accident...):

If you have a complex class hierarchy, it would be quite complex to find
out the correct common sub-type. Using only .fromElemenst(Class<X>,
X...) requires to specify the correct sub-type and has the additional
advantage, the the compiler can check the type already (instead of a
potential later runtime error).


-Matthias


On 04/27/2016 03:07 PM, Till Rohrmann wrote:

> You’re completely right Mathias. The compiler shouldn’t allow something
> like env.fromElements(SubClass.class, new ParentClass()) if it weren’t for
> the overloaded method. Thus, the test case is somewhat bogus.
>
> I’m actually wondering why the initial problem
> https://issues.apache.org/jira/browse/FLINK-3444 was solved this way. I
> think it would be better to automatically infer the common super type of
> all provided elements. Otherwise, you run into problems you’ve found out
> about.
>
> Consequently, I think it is fine if you remove the fromElementsWithBaseType2
> test case.
>
> Cheers,
> Till
> ​
>
> On Wed, Apr 27, 2016 at 1:22 PM, Matthias J. Sax <[hidden email]> wrote:
>
>> Hi Till,
>>
>> but StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2 does not
>> test was you describe -- even if it is intended to test it.
>>
>> It would test your describe scenario, if fromElements(Class<X>, X...)
>> would be called, But this call is not possible because X is defined a
>> type Subclass and thus the provided object of Parentclass cannot be
>> handed over as type X. Therefore, fromElements(Object...) is called: of
>> course, this fails too, because now the type is derived as
>> Class<Subclass> (and not Subclass) and neither Subclass nor Parentclass
>> inherit from Class<Subclass>.
>>
>> The scenario you describe will never work -- if you remove the overload
>> fromElements(Object...) the code would not even compile as the compiler
>> can figure out from the generics that the call
>> fromElments(Subclass.class, new Parentclass()) is invalid.
>>
>> It is only possible to hand in "reverse inheritance types" for
>> fromElemenst(Object...). In this case, the first given Object defines
>> the type. Thus, if you call fromElements(new Subclass(), new
>> Parentclass()), the call will fail, as Parentclass is no subtype of
>> Subtype -- the call fromElements(new Parentclass() new Subclass()) would
>> succeed.
>>
>> Makes sense?
>>
>> Still no idea how to make it compile in Eclipse...
>>
>> -Matthias
>>
>> On 04/27/2016 10:21 AM, Till Rohrmann wrote:
>>> Thanks for looking into this problem Mathias. I think the Scala test
>> should
>>> be fixed as you've proposed.
>>>
>>> Concerning the
>> StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2,
>>> I think it shouldn't be changed. The reason is that the class defines the
>>> common base class of the elements. And the test makes sure that the
>>> fromElements call fails if you provide instances which are not of the
>>> specified type or a subclass of it. Thus, we should find another way to
>>> make it work with Eclipse.
>>>
>>> Cheers,
>>> Till
>>>
>>> On Tue, Apr 26, 2016 at 9:41 PM, Matthias J. Sax <[hidden email]>
>> wrote:
>>>
>>>> Even if the fix works, I still have two issues in my Eclipse build...
>>>>
>>>> In
>>>>
>>>>
>>>>
>> flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>
>>>> Eclipse cannot infer the integer type. It could be fixed if you make the
>>>> type explicit (as this is only a test, it might be nice to fix this --
>>>> let me know if I can push this or not)
>>>>
>>>>> diff --git
>>>>
>> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>
>> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>> index c2e13fe..f9ce3b8 100644
>>>>> ---
>>>>
>> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>> +++
>>>>
>> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>> @@ -29,7 +29,7 @@ private[extensions] abstract class AcceptPFTestBase
>>>> extends TestLogger with JUni
>>>>>
>>>>>    private val env = ExecutionEnvironment.getExecutionEnvironment
>>>>>
>>>>> -  protected val tuples = env.fromElements(1 -> "hello", 2 -> "world")
>>>>> +  protected val tuples = env.fromElements(new Integer(1) -> "hello",
>>>> new Integer(2) -> "world")
>>>>>    protected val caseObjects = env.fromElements(KeyValuePair(1,
>>>> "hello"), KeyValuePair(2, "world"))
>>>>>
>>>>>    protected val groupedTuples = tuples.groupBy(_._1)
>>>>
>>>> Furthermore, in
>>>>
>>>>
>> flink-java/src/test/java/org/apache/flink/api/java/io/FromElementsTest.java
>>>>
>>>>> @Test
>>>>> public void fromElementsWithBaseTypeTest1() {
>>>>>       ExecutionEnvironment executionEnvironment =
>>>> ExecutionEnvironment.getExecutionEnvironment();
>>>>>       executionEnvironment.fromElements(ParentType.class, new
>> SubType(1,
>>>> "Java"), new ParentType(1, "hello"));
>>>>> }
>>>>
>>>> and in
>>>>
>>>>
>>>>
>> flink-streaming-java/src/test/java/org/apache/flink/streaming/api/StreamExecutionEnvironmentTest.java
>>>>
>>>>> @Test
>>>>> public void fromElementsWithBaseTypeTest1() {
>>>>>       StreamExecutionEnvironment env =
>>>> StreamExecutionEnvironment.getExecutionEnvironment();
>>>>>       env.fromElements(ParentClass.class, new SubClass(1, "Java"), new
>>>> ParentClass(1, "hello"));
>>>>> }
>>>>
>>>> In both cases, I get the error:
>>>>
>>>>   The method .fromElements(Object[]) is ambiguous
>>>>
>>>> No clue how to fix this, and why Eclipse does not bind to
>>>> .fromElements(Class<X>, X). Any ideas?
>>>>
>>>> I also digger a little bit and for both test-classes there is a second
>>>> test method called "fromElementsWithBaseTypeTest2". If I understand this
>>>> test correctly, it also tries to bind to .fromElements(Class<X>, X), but
>>>> this does not happen and .fromElemenst(Object[]) is called. Even if
>>>> there is still an exception, I got the impression that this test does
>>>> not what the intention was.
>>>>
>>>> If might be good to change fromElementsWithBaseTypeTest2 to
>>>>
>>>>> env.fromElements(new SubClass(1, "Java"), new ParentClass(1, "hello"));
>>>>
>>>> (ie, remove the first Class parameter). Any comments on this?
>>>>
>>>> -Matthias
>>>>
>>>>
>>>>
>>>> On 04/25/2016 01:42 PM, Robert Metzger wrote:
>>>>> Cool, thank you for working on this!
>>>>>
>>>>> On Mon, Apr 25, 2016 at 1:37 PM, Matthias J. Sax <[hidden email]>
>>>> wrote:
>>>>>
>>>>>> I can confirm that the SO answer works.
>>>>>>
>>>>>> I will add a note to the Eclipse setup guide at the web site.
>>>>>>
>>>>>> -Matthias
>>>>>>
>>>>>>
>>>>>> On 04/25/2016 11:33 AM, Robert Metzger wrote:
>>>>>>> It seems that the user resolved the issue on SO, right?
>>>>>>>
>>>>>>> On Mon, Apr 25, 2016 at 11:31 AM, Ufuk Celebi <[hidden email]>
>> wrote:
>>>>>>>
>>>>>>>> On Mon, Apr 25, 2016 at 12:14 AM, Matthias J. Sax <[hidden email]
>>>
>>>>>>>> wrote:
>>>>>>>>> What do you think about this?
>>>>>>>>
>>>>>>>> Hey Matthias!
>>>>>>>>
>>>>>>>> Thanks for bringing this up.
>>>>>>>>
>>>>>>>> I think it is very desirable to keep support for Eclipse. It's
>> quite a
>>>>>>>> high barrier for new contributors to enforce a specific IDE
>> (although
>>>>>>>> IntelliJ is gaining quite the user base I think :P).
>>>>>>>>
>>>>>>>> Do you have time to look into this?
>>>>>>>>
>>>>>>>> – Ufuk
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Problems

Till Rohrmann
I don't know whether it is that difficult to find out the nearest common
super type. At least the Java compiler does the same when calling the pure
var arg method. I think, we should be able to do something similar. Also
throwing out the pure var arg implementation is not ideal in my opinion,
because this would force the user to always specify class objects even
though he's providing only a set of strings, for example.

On Wed, Apr 27, 2016 at 4:25 PM, Matthias J. Sax <[hidden email]> wrote:

> I guess, removing .fromElements(Object..) would fix the problem. Not
> sure so, if we can remove the method due to API stability...
>
> I don't see any other good solution (even if the current implementation
> gives a nice behavior by accident...):
>
> If you have a complex class hierarchy, it would be quite complex to find
> out the correct common sub-type. Using only .fromElemenst(Class<X>,
> X...) requires to specify the correct sub-type and has the additional
> advantage, the the compiler can check the type already (instead of a
> potential later runtime error).
>
>
> -Matthias
>
>
> On 04/27/2016 03:07 PM, Till Rohrmann wrote:
> > You’re completely right Mathias. The compiler shouldn’t allow something
> > like env.fromElements(SubClass.class, new ParentClass()) if it weren’t
> for
> > the overloaded method. Thus, the test case is somewhat bogus.
> >
> > I’m actually wondering why the initial problem
> > https://issues.apache.org/jira/browse/FLINK-3444 was solved this way. I
> > think it would be better to automatically infer the common super type of
> > all provided elements. Otherwise, you run into problems you’ve found out
> > about.
> >
> > Consequently, I think it is fine if you remove the
> fromElementsWithBaseType2
> > test case.
> >
> > Cheers,
> > Till
> > ​
> >
> > On Wed, Apr 27, 2016 at 1:22 PM, Matthias J. Sax <[hidden email]>
> wrote:
> >
> >> Hi Till,
> >>
> >> but StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2 does not
> >> test was you describe -- even if it is intended to test it.
> >>
> >> It would test your describe scenario, if fromElements(Class<X>, X...)
> >> would be called, But this call is not possible because X is defined a
> >> type Subclass and thus the provided object of Parentclass cannot be
> >> handed over as type X. Therefore, fromElements(Object...) is called: of
> >> course, this fails too, because now the type is derived as
> >> Class<Subclass> (and not Subclass) and neither Subclass nor Parentclass
> >> inherit from Class<Subclass>.
> >>
> >> The scenario you describe will never work -- if you remove the overload
> >> fromElements(Object...) the code would not even compile as the compiler
> >> can figure out from the generics that the call
> >> fromElments(Subclass.class, new Parentclass()) is invalid.
> >>
> >> It is only possible to hand in "reverse inheritance types" for
> >> fromElemenst(Object...). In this case, the first given Object defines
> >> the type. Thus, if you call fromElements(new Subclass(), new
> >> Parentclass()), the call will fail, as Parentclass is no subtype of
> >> Subtype -- the call fromElements(new Parentclass() new Subclass()) would
> >> succeed.
> >>
> >> Makes sense?
> >>
> >> Still no idea how to make it compile in Eclipse...
> >>
> >> -Matthias
> >>
> >> On 04/27/2016 10:21 AM, Till Rohrmann wrote:
> >>> Thanks for looking into this problem Mathias. I think the Scala test
> >> should
> >>> be fixed as you've proposed.
> >>>
> >>> Concerning the
> >> StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2,
> >>> I think it shouldn't be changed. The reason is that the class defines
> the
> >>> common base class of the elements. And the test makes sure that the
> >>> fromElements call fails if you provide instances which are not of the
> >>> specified type or a subclass of it. Thus, we should find another way to
> >>> make it work with Eclipse.
> >>>
> >>> Cheers,
> >>> Till
> >>>
> >>> On Tue, Apr 26, 2016 at 9:41 PM, Matthias J. Sax <[hidden email]>
> >> wrote:
> >>>
> >>>> Even if the fix works, I still have two issues in my Eclipse build...
> >>>>
> >>>> In
> >>>>
> >>>>
> >>>>
> >>
> flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>>>
> >>>> Eclipse cannot infer the integer type. It could be fixed if you make
> the
> >>>> type explicit (as this is only a test, it might be nice to fix this --
> >>>> let me know if I can push this or not)
> >>>>
> >>>>> diff --git
> >>>>
> >>
> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>>>
> >>
> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>>>> index c2e13fe..f9ce3b8 100644
> >>>>> ---
> >>>>
> >>
> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>>>> +++
> >>>>
> >>
> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>>>> @@ -29,7 +29,7 @@ private[extensions] abstract class AcceptPFTestBase
> >>>> extends TestLogger with JUni
> >>>>>
> >>>>>    private val env = ExecutionEnvironment.getExecutionEnvironment
> >>>>>
> >>>>> -  protected val tuples = env.fromElements(1 -> "hello", 2 ->
> "world")
> >>>>> +  protected val tuples = env.fromElements(new Integer(1) -> "hello",
> >>>> new Integer(2) -> "world")
> >>>>>    protected val caseObjects = env.fromElements(KeyValuePair(1,
> >>>> "hello"), KeyValuePair(2, "world"))
> >>>>>
> >>>>>    protected val groupedTuples = tuples.groupBy(_._1)
> >>>>
> >>>> Furthermore, in
> >>>>
> >>>>
> >>
> flink-java/src/test/java/org/apache/flink/api/java/io/FromElementsTest.java
> >>>>
> >>>>> @Test
> >>>>> public void fromElementsWithBaseTypeTest1() {
> >>>>>       ExecutionEnvironment executionEnvironment =
> >>>> ExecutionEnvironment.getExecutionEnvironment();
> >>>>>       executionEnvironment.fromElements(ParentType.class, new
> >> SubType(1,
> >>>> "Java"), new ParentType(1, "hello"));
> >>>>> }
> >>>>
> >>>> and in
> >>>>
> >>>>
> >>>>
> >>
> flink-streaming-java/src/test/java/org/apache/flink/streaming/api/StreamExecutionEnvironmentTest.java
> >>>>
> >>>>> @Test
> >>>>> public void fromElementsWithBaseTypeTest1() {
> >>>>>       StreamExecutionEnvironment env =
> >>>> StreamExecutionEnvironment.getExecutionEnvironment();
> >>>>>       env.fromElements(ParentClass.class, new SubClass(1, "Java"),
> new
> >>>> ParentClass(1, "hello"));
> >>>>> }
> >>>>
> >>>> In both cases, I get the error:
> >>>>
> >>>>   The method .fromElements(Object[]) is ambiguous
> >>>>
> >>>> No clue how to fix this, and why Eclipse does not bind to
> >>>> .fromElements(Class<X>, X). Any ideas?
> >>>>
> >>>> I also digger a little bit and for both test-classes there is a second
> >>>> test method called "fromElementsWithBaseTypeTest2". If I understand
> this
> >>>> test correctly, it also tries to bind to .fromElements(Class<X>, X),
> but
> >>>> this does not happen and .fromElemenst(Object[]) is called. Even if
> >>>> there is still an exception, I got the impression that this test does
> >>>> not what the intention was.
> >>>>
> >>>> If might be good to change fromElementsWithBaseTypeTest2 to
> >>>>
> >>>>> env.fromElements(new SubClass(1, "Java"), new ParentClass(1,
> "hello"));
> >>>>
> >>>> (ie, remove the first Class parameter). Any comments on this?
> >>>>
> >>>> -Matthias
> >>>>
> >>>>
> >>>>
> >>>> On 04/25/2016 01:42 PM, Robert Metzger wrote:
> >>>>> Cool, thank you for working on this!
> >>>>>
> >>>>> On Mon, Apr 25, 2016 at 1:37 PM, Matthias J. Sax <[hidden email]>
> >>>> wrote:
> >>>>>
> >>>>>> I can confirm that the SO answer works.
> >>>>>>
> >>>>>> I will add a note to the Eclipse setup guide at the web site.
> >>>>>>
> >>>>>> -Matthias
> >>>>>>
> >>>>>>
> >>>>>> On 04/25/2016 11:33 AM, Robert Metzger wrote:
> >>>>>>> It seems that the user resolved the issue on SO, right?
> >>>>>>>
> >>>>>>> On Mon, Apr 25, 2016 at 11:31 AM, Ufuk Celebi <[hidden email]>
> >> wrote:
> >>>>>>>
> >>>>>>>> On Mon, Apr 25, 2016 at 12:14 AM, Matthias J. Sax <
> [hidden email]
> >>>
> >>>>>>>> wrote:
> >>>>>>>>> What do you think about this?
> >>>>>>>>
> >>>>>>>> Hey Matthias!
> >>>>>>>>
> >>>>>>>> Thanks for bringing this up.
> >>>>>>>>
> >>>>>>>> I think it is very desirable to keep support for Eclipse. It's
> >> quite a
> >>>>>>>> high barrier for new contributors to enforce a specific IDE
> >> (although
> >>>>>>>> IntelliJ is gaining quite the user base I think :P).
> >>>>>>>>
> >>>>>>>> Do you have time to look into this?
> >>>>>>>>
> >>>>>>>> – Ufuk
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Problems

Matthias J. Sax-2
Maybe.

As we cannot change the interface anyway and is does what the user
expects (even if only "by accident") I would just leave it as is... And
for "mixed" types, specifying the common base class is acceptable
"overhead" for the user IMHO.

Nevertheless, the Eclipse problem is still not solved. Any ideas about this?

If not, I would just leave this problem open, too. It is "only" for two
test classes and not severe.

-Matthias

On 04/28/2016 10:13 AM, Till Rohrmann wrote:

> I don't know whether it is that difficult to find out the nearest common
> super type. At least the Java compiler does the same when calling the pure
> var arg method. I think, we should be able to do something similar. Also
> throwing out the pure var arg implementation is not ideal in my opinion,
> because this would force the user to always specify class objects even
> though he's providing only a set of strings, for example.
>
> On Wed, Apr 27, 2016 at 4:25 PM, Matthias J. Sax <[hidden email]> wrote:
>
>> I guess, removing .fromElements(Object..) would fix the problem. Not
>> sure so, if we can remove the method due to API stability...
>>
>> I don't see any other good solution (even if the current implementation
>> gives a nice behavior by accident...):
>>
>> If you have a complex class hierarchy, it would be quite complex to find
>> out the correct common sub-type. Using only .fromElemenst(Class<X>,
>> X...) requires to specify the correct sub-type and has the additional
>> advantage, the the compiler can check the type already (instead of a
>> potential later runtime error).
>>
>>
>> -Matthias
>>
>>
>> On 04/27/2016 03:07 PM, Till Rohrmann wrote:
>>> You’re completely right Mathias. The compiler shouldn’t allow something
>>> like env.fromElements(SubClass.class, new ParentClass()) if it weren’t
>> for
>>> the overloaded method. Thus, the test case is somewhat bogus.
>>>
>>> I’m actually wondering why the initial problem
>>> https://issues.apache.org/jira/browse/FLINK-3444 was solved this way. I
>>> think it would be better to automatically infer the common super type of
>>> all provided elements. Otherwise, you run into problems you’ve found out
>>> about.
>>>
>>> Consequently, I think it is fine if you remove the
>> fromElementsWithBaseType2
>>> test case.
>>>
>>> Cheers,
>>> Till
>>> ​
>>>
>>> On Wed, Apr 27, 2016 at 1:22 PM, Matthias J. Sax <[hidden email]>
>> wrote:
>>>
>>>> Hi Till,
>>>>
>>>> but StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2 does not
>>>> test was you describe -- even if it is intended to test it.
>>>>
>>>> It would test your describe scenario, if fromElements(Class<X>, X...)
>>>> would be called, But this call is not possible because X is defined a
>>>> type Subclass and thus the provided object of Parentclass cannot be
>>>> handed over as type X. Therefore, fromElements(Object...) is called: of
>>>> course, this fails too, because now the type is derived as
>>>> Class<Subclass> (and not Subclass) and neither Subclass nor Parentclass
>>>> inherit from Class<Subclass>.
>>>>
>>>> The scenario you describe will never work -- if you remove the overload
>>>> fromElements(Object...) the code would not even compile as the compiler
>>>> can figure out from the generics that the call
>>>> fromElments(Subclass.class, new Parentclass()) is invalid.
>>>>
>>>> It is only possible to hand in "reverse inheritance types" for
>>>> fromElemenst(Object...). In this case, the first given Object defines
>>>> the type. Thus, if you call fromElements(new Subclass(), new
>>>> Parentclass()), the call will fail, as Parentclass is no subtype of
>>>> Subtype -- the call fromElements(new Parentclass() new Subclass()) would
>>>> succeed.
>>>>
>>>> Makes sense?
>>>>
>>>> Still no idea how to make it compile in Eclipse...
>>>>
>>>> -Matthias
>>>>
>>>> On 04/27/2016 10:21 AM, Till Rohrmann wrote:
>>>>> Thanks for looking into this problem Mathias. I think the Scala test
>>>> should
>>>>> be fixed as you've proposed.
>>>>>
>>>>> Concerning the
>>>> StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2,
>>>>> I think it shouldn't be changed. The reason is that the class defines
>> the
>>>>> common base class of the elements. And the test makes sure that the
>>>>> fromElements call fails if you provide instances which are not of the
>>>>> specified type or a subclass of it. Thus, we should find another way to
>>>>> make it work with Eclipse.
>>>>>
>>>>> Cheers,
>>>>> Till
>>>>>
>>>>> On Tue, Apr 26, 2016 at 9:41 PM, Matthias J. Sax <[hidden email]>
>>>> wrote:
>>>>>
>>>>>> Even if the fix works, I still have two issues in my Eclipse build...
>>>>>>
>>>>>> In
>>>>>>
>>>>>>
>>>>>>
>>>>
>> flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>>>
>>>>>> Eclipse cannot infer the integer type. It could be fixed if you make
>> the
>>>>>> type explicit (as this is only a test, it might be nice to fix this --
>>>>>> let me know if I can push this or not)
>>>>>>
>>>>>>> diff --git
>>>>>>
>>>>
>> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>>>
>>>>
>> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>>>> index c2e13fe..f9ce3b8 100644
>>>>>>> ---
>>>>>>
>>>>
>> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>>>> +++
>>>>>>
>>>>
>> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>>>> @@ -29,7 +29,7 @@ private[extensions] abstract class AcceptPFTestBase
>>>>>> extends TestLogger with JUni
>>>>>>>
>>>>>>>    private val env = ExecutionEnvironment.getExecutionEnvironment
>>>>>>>
>>>>>>> -  protected val tuples = env.fromElements(1 -> "hello", 2 ->
>> "world")
>>>>>>> +  protected val tuples = env.fromElements(new Integer(1) -> "hello",
>>>>>> new Integer(2) -> "world")
>>>>>>>    protected val caseObjects = env.fromElements(KeyValuePair(1,
>>>>>> "hello"), KeyValuePair(2, "world"))
>>>>>>>
>>>>>>>    protected val groupedTuples = tuples.groupBy(_._1)
>>>>>>
>>>>>> Furthermore, in
>>>>>>
>>>>>>
>>>>
>> flink-java/src/test/java/org/apache/flink/api/java/io/FromElementsTest.java
>>>>>>
>>>>>>> @Test
>>>>>>> public void fromElementsWithBaseTypeTest1() {
>>>>>>>       ExecutionEnvironment executionEnvironment =
>>>>>> ExecutionEnvironment.getExecutionEnvironment();
>>>>>>>       executionEnvironment.fromElements(ParentType.class, new
>>>> SubType(1,
>>>>>> "Java"), new ParentType(1, "hello"));
>>>>>>> }
>>>>>>
>>>>>> and in
>>>>>>
>>>>>>
>>>>>>
>>>>
>> flink-streaming-java/src/test/java/org/apache/flink/streaming/api/StreamExecutionEnvironmentTest.java
>>>>>>
>>>>>>> @Test
>>>>>>> public void fromElementsWithBaseTypeTest1() {
>>>>>>>       StreamExecutionEnvironment env =
>>>>>> StreamExecutionEnvironment.getExecutionEnvironment();
>>>>>>>       env.fromElements(ParentClass.class, new SubClass(1, "Java"),
>> new
>>>>>> ParentClass(1, "hello"));
>>>>>>> }
>>>>>>
>>>>>> In both cases, I get the error:
>>>>>>
>>>>>>   The method .fromElements(Object[]) is ambiguous
>>>>>>
>>>>>> No clue how to fix this, and why Eclipse does not bind to
>>>>>> .fromElements(Class<X>, X). Any ideas?
>>>>>>
>>>>>> I also digger a little bit and for both test-classes there is a second
>>>>>> test method called "fromElementsWithBaseTypeTest2". If I understand
>> this
>>>>>> test correctly, it also tries to bind to .fromElements(Class<X>, X),
>> but
>>>>>> this does not happen and .fromElemenst(Object[]) is called. Even if
>>>>>> there is still an exception, I got the impression that this test does
>>>>>> not what the intention was.
>>>>>>
>>>>>> If might be good to change fromElementsWithBaseTypeTest2 to
>>>>>>
>>>>>>> env.fromElements(new SubClass(1, "Java"), new ParentClass(1,
>> "hello"));
>>>>>>
>>>>>> (ie, remove the first Class parameter). Any comments on this?
>>>>>>
>>>>>> -Matthias
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 04/25/2016 01:42 PM, Robert Metzger wrote:
>>>>>>> Cool, thank you for working on this!
>>>>>>>
>>>>>>> On Mon, Apr 25, 2016 at 1:37 PM, Matthias J. Sax <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>>> I can confirm that the SO answer works.
>>>>>>>>
>>>>>>>> I will add a note to the Eclipse setup guide at the web site.
>>>>>>>>
>>>>>>>> -Matthias
>>>>>>>>
>>>>>>>>
>>>>>>>> On 04/25/2016 11:33 AM, Robert Metzger wrote:
>>>>>>>>> It seems that the user resolved the issue on SO, right?
>>>>>>>>>
>>>>>>>>> On Mon, Apr 25, 2016 at 11:31 AM, Ufuk Celebi <[hidden email]>
>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Mon, Apr 25, 2016 at 12:14 AM, Matthias J. Sax <
>> [hidden email]
>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>> What do you think about this?
>>>>>>>>>>
>>>>>>>>>> Hey Matthias!
>>>>>>>>>>
>>>>>>>>>> Thanks for bringing this up.
>>>>>>>>>>
>>>>>>>>>> I think it is very desirable to keep support for Eclipse. It's
>>>> quite a
>>>>>>>>>> high barrier for new contributors to enforce a specific IDE
>>>> (although
>>>>>>>>>> IntelliJ is gaining quite the user base I think :P).
>>>>>>>>>>
>>>>>>>>>> Do you have time to look into this?
>>>>>>>>>>
>>>>>>>>>> – Ufuk
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Problems

Greg Hogan
In reply to this post by Matthias J. Sax-2
Matthias,

Won't this be a compile-time error as long as the user is parameterizing
the return type since .fromElements(OUT...) returns DataStreamSource<OUT>
and will bind to the nearest common superclass? The new
.fromElements(Class<OUT>, OUT...) does give the user the choice of common
superclass.

Greg


On Wed, Apr 27, 2016 at 10:25 AM, Matthias J. Sax <[hidden email]> wrote:

> I guess, removing .fromElements(Object..) would fix the problem. Not
> sure so, if we can remove the method due to API stability...
>
> I don't see any other good solution (even if the current implementation
> gives a nice behavior by accident...):
>
> If you have a complex class hierarchy, it would be quite complex to find
> out the correct common sub-type. Using only .fromElemenst(Class<X>,
> X...) requires to specify the correct sub-type and has the additional
> advantage, the the compiler can check the type already (instead of a
> potential later runtime error).
>
>
> -Matthias
>
>
> On 04/27/2016 03:07 PM, Till Rohrmann wrote:
> > You’re completely right Mathias. The compiler shouldn’t allow something
> > like env.fromElements(SubClass.class, new ParentClass()) if it weren’t
> for
> > the overloaded method. Thus, the test case is somewhat bogus.
> >
> > I’m actually wondering why the initial problem
> > https://issues.apache.org/jira/browse/FLINK-3444 was solved this way. I
> > think it would be better to automatically infer the common super type of
> > all provided elements. Otherwise, you run into problems you’ve found out
> > about.
> >
> > Consequently, I think it is fine if you remove the
> fromElementsWithBaseType2
> > test case.
> >
> > Cheers,
> > Till
> > ​
> >
> > On Wed, Apr 27, 2016 at 1:22 PM, Matthias J. Sax <[hidden email]>
> wrote:
> >
> >> Hi Till,
> >>
> >> but StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2 does not
> >> test was you describe -- even if it is intended to test it.
> >>
> >> It would test your describe scenario, if fromElements(Class<X>, X...)
> >> would be called, But this call is not possible because X is defined a
> >> type Subclass and thus the provided object of Parentclass cannot be
> >> handed over as type X. Therefore, fromElements(Object...) is called: of
> >> course, this fails too, because now the type is derived as
> >> Class<Subclass> (and not Subclass) and neither Subclass nor Parentclass
> >> inherit from Class<Subclass>.
> >>
> >> The scenario you describe will never work -- if you remove the overload
> >> fromElements(Object...) the code would not even compile as the compiler
> >> can figure out from the generics that the call
> >> fromElments(Subclass.class, new Parentclass()) is invalid.
> >>
> >> It is only possible to hand in "reverse inheritance types" for
> >> fromElemenst(Object...). In this case, the first given Object defines
> >> the type. Thus, if you call fromElements(new Subclass(), new
> >> Parentclass()), the call will fail, as Parentclass is no subtype of
> >> Subtype -- the call fromElements(new Parentclass() new Subclass()) would
> >> succeed.
> >>
> >> Makes sense?
> >>
> >> Still no idea how to make it compile in Eclipse...
> >>
> >> -Matthias
> >>
> >> On 04/27/2016 10:21 AM, Till Rohrmann wrote:
> >>> Thanks for looking into this problem Mathias. I think the Scala test
> >> should
> >>> be fixed as you've proposed.
> >>>
> >>> Concerning the
> >> StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2,
> >>> I think it shouldn't be changed. The reason is that the class defines
> the
> >>> common base class of the elements. And the test makes sure that the
> >>> fromElements call fails if you provide instances which are not of the
> >>> specified type or a subclass of it. Thus, we should find another way to
> >>> make it work with Eclipse.
> >>>
> >>> Cheers,
> >>> Till
> >>>
> >>> On Tue, Apr 26, 2016 at 9:41 PM, Matthias J. Sax <[hidden email]>
> >> wrote:
> >>>
> >>>> Even if the fix works, I still have two issues in my Eclipse build...
> >>>>
> >>>> In
> >>>>
> >>>>
> >>>>
> >>
> flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>>>
> >>>> Eclipse cannot infer the integer type. It could be fixed if you make
> the
> >>>> type explicit (as this is only a test, it might be nice to fix this --
> >>>> let me know if I can push this or not)
> >>>>
> >>>>> diff --git
> >>>>
> >>
> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>>>
> >>
> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>>>> index c2e13fe..f9ce3b8 100644
> >>>>> ---
> >>>>
> >>
> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>>>> +++
> >>>>
> >>
> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
> >>>>> @@ -29,7 +29,7 @@ private[extensions] abstract class AcceptPFTestBase
> >>>> extends TestLogger with JUni
> >>>>>
> >>>>>    private val env = ExecutionEnvironment.getExecutionEnvironment
> >>>>>
> >>>>> -  protected val tuples = env.fromElements(1 -> "hello", 2 ->
> "world")
> >>>>> +  protected val tuples = env.fromElements(new Integer(1) -> "hello",
> >>>> new Integer(2) -> "world")
> >>>>>    protected val caseObjects = env.fromElements(KeyValuePair(1,
> >>>> "hello"), KeyValuePair(2, "world"))
> >>>>>
> >>>>>    protected val groupedTuples = tuples.groupBy(_._1)
> >>>>
> >>>> Furthermore, in
> >>>>
> >>>>
> >>
> flink-java/src/test/java/org/apache/flink/api/java/io/FromElementsTest.java
> >>>>
> >>>>> @Test
> >>>>> public void fromElementsWithBaseTypeTest1() {
> >>>>>       ExecutionEnvironment executionEnvironment =
> >>>> ExecutionEnvironment.getExecutionEnvironment();
> >>>>>       executionEnvironment.fromElements(ParentType.class, new
> >> SubType(1,
> >>>> "Java"), new ParentType(1, "hello"));
> >>>>> }
> >>>>
> >>>> and in
> >>>>
> >>>>
> >>>>
> >>
> flink-streaming-java/src/test/java/org/apache/flink/streaming/api/StreamExecutionEnvironmentTest.java
> >>>>
> >>>>> @Test
> >>>>> public void fromElementsWithBaseTypeTest1() {
> >>>>>       StreamExecutionEnvironment env =
> >>>> StreamExecutionEnvironment.getExecutionEnvironment();
> >>>>>       env.fromElements(ParentClass.class, new SubClass(1, "Java"),
> new
> >>>> ParentClass(1, "hello"));
> >>>>> }
> >>>>
> >>>> In both cases, I get the error:
> >>>>
> >>>>   The method .fromElements(Object[]) is ambiguous
> >>>>
> >>>> No clue how to fix this, and why Eclipse does not bind to
> >>>> .fromElements(Class<X>, X). Any ideas?
> >>>>
> >>>> I also digger a little bit and for both test-classes there is a second
> >>>> test method called "fromElementsWithBaseTypeTest2". If I understand
> this
> >>>> test correctly, it also tries to bind to .fromElements(Class<X>, X),
> but
> >>>> this does not happen and .fromElemenst(Object[]) is called. Even if
> >>>> there is still an exception, I got the impression that this test does
> >>>> not what the intention was.
> >>>>
> >>>> If might be good to change fromElementsWithBaseTypeTest2 to
> >>>>
> >>>>> env.fromElements(new SubClass(1, "Java"), new ParentClass(1,
> "hello"));
> >>>>
> >>>> (ie, remove the first Class parameter). Any comments on this?
> >>>>
> >>>> -Matthias
> >>>>
> >>>>
> >>>>
> >>>> On 04/25/2016 01:42 PM, Robert Metzger wrote:
> >>>>> Cool, thank you for working on this!
> >>>>>
> >>>>> On Mon, Apr 25, 2016 at 1:37 PM, Matthias J. Sax <[hidden email]>
> >>>> wrote:
> >>>>>
> >>>>>> I can confirm that the SO answer works.
> >>>>>>
> >>>>>> I will add a note to the Eclipse setup guide at the web site.
> >>>>>>
> >>>>>> -Matthias
> >>>>>>
> >>>>>>
> >>>>>> On 04/25/2016 11:33 AM, Robert Metzger wrote:
> >>>>>>> It seems that the user resolved the issue on SO, right?
> >>>>>>>
> >>>>>>> On Mon, Apr 25, 2016 at 11:31 AM, Ufuk Celebi <[hidden email]>
> >> wrote:
> >>>>>>>
> >>>>>>>> On Mon, Apr 25, 2016 at 12:14 AM, Matthias J. Sax <
> [hidden email]
> >>>
> >>>>>>>> wrote:
> >>>>>>>>> What do you think about this?
> >>>>>>>>
> >>>>>>>> Hey Matthias!
> >>>>>>>>
> >>>>>>>> Thanks for bringing this up.
> >>>>>>>>
> >>>>>>>> I think it is very desirable to keep support for Eclipse. It's
> >> quite a
> >>>>>>>> high barrier for new contributors to enforce a specific IDE
> >> (although
> >>>>>>>> IntelliJ is gaining quite the user base I think :P).
> >>>>>>>>
> >>>>>>>> Do you have time to look into this?
> >>>>>>>>
> >>>>>>>> – Ufuk
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Problems

Matthias J. Sax-2
Hi Greg,

Not sure if you followed the whole thread. The "main" problem discussed
here is, that Eclipse does show an compile error for some tests that
actually compile via maven.

The tests uses a ParentClass and ChildClass and call

fromElements(ParentClass.class, new ParentClass(), new ChildClass())

Eclipse complains about ambiguous method because it can bind the call to
either

fromElements(Class<ParentClass>, ParentClass...)
or
fromElements(Object...)

What basically makes sense -- not sure why maven build does resolve this
differently -- but I am not an expert how Java resolves methods with
regard to cast and/or generics. The better binding is of course the
first one and I am not sure, why Eclipse does not pick it.


The other "problem" is a second test that calls

fromElements(ChildClass.class, new ParentClass(), new ChildClass())

This should raise an exception as ParentClass does not inherit from
ChildClass. The point is, that this call does not bind to

fromElements(Class<ChildClass>, ChildClass...)

because the compiler discovers that ParentClass and ChildClass are not
compatible here. Thus, there is only

fromElements(Object...)

left to bind, what of course always works... (ie, no compile error and
no ambiguous overload for the method any more). However internally, the
type is inferred as Class<ChildClass> (the type of the first argument)
instead of ChildClass. This still fails, because Child<ChildClass> is no
supertype of ChildClass nor ParentClass.

But the test is somewhat weird, because actually the type should be
ChildClass and fail because ParentClass has not supertype ChildClass.



-Matthias


On 04/28/2016 03:42 PM, Greg Hogan wrote:

> Matthias,
>
> Won't this be a compile-time error as long as the user is parameterizing
> the return type since .fromElements(OUT...) returns DataStreamSource<OUT>
> and will bind to the nearest common superclass? The new
> .fromElements(Class<OUT>, OUT...) does give the user the choice of common
> superclass.
>
> Greg
>
>
> On Wed, Apr 27, 2016 at 10:25 AM, Matthias J. Sax <[hidden email]> wrote:
>
>> I guess, removing .fromElements(Object..) would fix the problem. Not
>> sure so, if we can remove the method due to API stability...
>>
>> I don't see any other good solution (even if the current implementation
>> gives a nice behavior by accident...):
>>
>> If you have a complex class hierarchy, it would be quite complex to find
>> out the correct common sub-type. Using only .fromElemenst(Class<X>,
>> X...) requires to specify the correct sub-type and has the additional
>> advantage, the the compiler can check the type already (instead of a
>> potential later runtime error).
>>
>>
>> -Matthias
>>
>>
>> On 04/27/2016 03:07 PM, Till Rohrmann wrote:
>>> You’re completely right Mathias. The compiler shouldn’t allow something
>>> like env.fromElements(SubClass.class, new ParentClass()) if it weren’t
>> for
>>> the overloaded method. Thus, the test case is somewhat bogus.
>>>
>>> I’m actually wondering why the initial problem
>>> https://issues.apache.org/jira/browse/FLINK-3444 was solved this way. I
>>> think it would be better to automatically infer the common super type of
>>> all provided elements. Otherwise, you run into problems you’ve found out
>>> about.
>>>
>>> Consequently, I think it is fine if you remove the
>> fromElementsWithBaseType2
>>> test case.
>>>
>>> Cheers,
>>> Till
>>> ​
>>>
>>> On Wed, Apr 27, 2016 at 1:22 PM, Matthias J. Sax <[hidden email]>
>> wrote:
>>>
>>>> Hi Till,
>>>>
>>>> but StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2 does not
>>>> test was you describe -- even if it is intended to test it.
>>>>
>>>> It would test your describe scenario, if fromElements(Class<X>, X...)
>>>> would be called, But this call is not possible because X is defined a
>>>> type Subclass and thus the provided object of Parentclass cannot be
>>>> handed over as type X. Therefore, fromElements(Object...) is called: of
>>>> course, this fails too, because now the type is derived as
>>>> Class<Subclass> (and not Subclass) and neither Subclass nor Parentclass
>>>> inherit from Class<Subclass>.
>>>>
>>>> The scenario you describe will never work -- if you remove the overload
>>>> fromElements(Object...) the code would not even compile as the compiler
>>>> can figure out from the generics that the call
>>>> fromElments(Subclass.class, new Parentclass()) is invalid.
>>>>
>>>> It is only possible to hand in "reverse inheritance types" for
>>>> fromElemenst(Object...). In this case, the first given Object defines
>>>> the type. Thus, if you call fromElements(new Subclass(), new
>>>> Parentclass()), the call will fail, as Parentclass is no subtype of
>>>> Subtype -- the call fromElements(new Parentclass() new Subclass()) would
>>>> succeed.
>>>>
>>>> Makes sense?
>>>>
>>>> Still no idea how to make it compile in Eclipse...
>>>>
>>>> -Matthias
>>>>
>>>> On 04/27/2016 10:21 AM, Till Rohrmann wrote:
>>>>> Thanks for looking into this problem Mathias. I think the Scala test
>>>> should
>>>>> be fixed as you've proposed.
>>>>>
>>>>> Concerning the
>>>> StreamExecutionEnvironmentTest.fromElementWithBaseTypeTest2,
>>>>> I think it shouldn't be changed. The reason is that the class defines
>> the
>>>>> common base class of the elements. And the test makes sure that the
>>>>> fromElements call fails if you provide instances which are not of the
>>>>> specified type or a subclass of it. Thus, we should find another way to
>>>>> make it work with Eclipse.
>>>>>
>>>>> Cheers,
>>>>> Till
>>>>>
>>>>> On Tue, Apr 26, 2016 at 9:41 PM, Matthias J. Sax <[hidden email]>
>>>> wrote:
>>>>>
>>>>>> Even if the fix works, I still have two issues in my Eclipse build...
>>>>>>
>>>>>> In
>>>>>>
>>>>>>
>>>>>>
>>>>
>> flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>>>
>>>>>> Eclipse cannot infer the integer type. It could be fixed if you make
>> the
>>>>>> type explicit (as this is only a test, it might be nice to fix this --
>>>>>> let me know if I can push this or not)
>>>>>>
>>>>>>> diff --git
>>>>>>
>>>>
>> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>>>
>>>>
>> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>>>> index c2e13fe..f9ce3b8 100644
>>>>>>> ---
>>>>>>
>>>>
>> a/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>>>> +++
>>>>>>
>>>>
>> b/flink-scala/src/test/scala/org/apache/flink/api/scala/extensions/base/AcceptPFTestBase.scala
>>>>>>> @@ -29,7 +29,7 @@ private[extensions] abstract class AcceptPFTestBase
>>>>>> extends TestLogger with JUni
>>>>>>>
>>>>>>>    private val env = ExecutionEnvironment.getExecutionEnvironment
>>>>>>>
>>>>>>> -  protected val tuples = env.fromElements(1 -> "hello", 2 ->
>> "world")
>>>>>>> +  protected val tuples = env.fromElements(new Integer(1) -> "hello",
>>>>>> new Integer(2) -> "world")
>>>>>>>    protected val caseObjects = env.fromElements(KeyValuePair(1,
>>>>>> "hello"), KeyValuePair(2, "world"))
>>>>>>>
>>>>>>>    protected val groupedTuples = tuples.groupBy(_._1)
>>>>>>
>>>>>> Furthermore, in
>>>>>>
>>>>>>
>>>>
>> flink-java/src/test/java/org/apache/flink/api/java/io/FromElementsTest.java
>>>>>>
>>>>>>> @Test
>>>>>>> public void fromElementsWithBaseTypeTest1() {
>>>>>>>       ExecutionEnvironment executionEnvironment =
>>>>>> ExecutionEnvironment.getExecutionEnvironment();
>>>>>>>       executionEnvironment.fromElements(ParentType.class, new
>>>> SubType(1,
>>>>>> "Java"), new ParentType(1, "hello"));
>>>>>>> }
>>>>>>
>>>>>> and in
>>>>>>
>>>>>>
>>>>>>
>>>>
>> flink-streaming-java/src/test/java/org/apache/flink/streaming/api/StreamExecutionEnvironmentTest.java
>>>>>>
>>>>>>> @Test
>>>>>>> public void fromElementsWithBaseTypeTest1() {
>>>>>>>       StreamExecutionEnvironment env =
>>>>>> StreamExecutionEnvironment.getExecutionEnvironment();
>>>>>>>       env.fromElements(ParentClass.class, new SubClass(1, "Java"),
>> new
>>>>>> ParentClass(1, "hello"));
>>>>>>> }
>>>>>>
>>>>>> In both cases, I get the error:
>>>>>>
>>>>>>   The method .fromElements(Object[]) is ambiguous
>>>>>>
>>>>>> No clue how to fix this, and why Eclipse does not bind to
>>>>>> .fromElements(Class<X>, X). Any ideas?
>>>>>>
>>>>>> I also digger a little bit and for both test-classes there is a second
>>>>>> test method called "fromElementsWithBaseTypeTest2". If I understand
>> this
>>>>>> test correctly, it also tries to bind to .fromElements(Class<X>, X),
>> but
>>>>>> this does not happen and .fromElemenst(Object[]) is called. Even if
>>>>>> there is still an exception, I got the impression that this test does
>>>>>> not what the intention was.
>>>>>>
>>>>>> If might be good to change fromElementsWithBaseTypeTest2 to
>>>>>>
>>>>>>> env.fromElements(new SubClass(1, "Java"), new ParentClass(1,
>> "hello"));
>>>>>>
>>>>>> (ie, remove the first Class parameter). Any comments on this?
>>>>>>
>>>>>> -Matthias
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 04/25/2016 01:42 PM, Robert Metzger wrote:
>>>>>>> Cool, thank you for working on this!
>>>>>>>
>>>>>>> On Mon, Apr 25, 2016 at 1:37 PM, Matthias J. Sax <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>>> I can confirm that the SO answer works.
>>>>>>>>
>>>>>>>> I will add a note to the Eclipse setup guide at the web site.
>>>>>>>>
>>>>>>>> -Matthias
>>>>>>>>
>>>>>>>>
>>>>>>>> On 04/25/2016 11:33 AM, Robert Metzger wrote:
>>>>>>>>> It seems that the user resolved the issue on SO, right?
>>>>>>>>>
>>>>>>>>> On Mon, Apr 25, 2016 at 11:31 AM, Ufuk Celebi <[hidden email]>
>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Mon, Apr 25, 2016 at 12:14 AM, Matthias J. Sax <
>> [hidden email]
>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>> What do you think about this?
>>>>>>>>>>
>>>>>>>>>> Hey Matthias!
>>>>>>>>>>
>>>>>>>>>> Thanks for bringing this up.
>>>>>>>>>>
>>>>>>>>>> I think it is very desirable to keep support for Eclipse. It's
>>>> quite a
>>>>>>>>>> high barrier for new contributors to enforce a specific IDE
>>>> (although
>>>>>>>>>> IntelliJ is gaining quite the user base I think :P).
>>>>>>>>>>
>>>>>>>>>> Do you have time to look into this?
>>>>>>>>>>
>>>>>>>>>> – Ufuk
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


signature.asc (836 bytes) Download Attachment