You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Claudio Squarcella <sq...@dia.uniroma3.it> on 2012/01/26 15:30:40 UTC
[SANDBOX][GRAPH] Eclipse vs. latest version
Hi all,
I am experiencing a rather annoying issue with the latest version of
commons-graph on Eclipse. Compiling with javac (maven, command line) it
works fine, but the editor still complains: e.g. line 72 of the new
FordFulkersonTestCase[1] gives a list of errors[2].
Now, I know from googling that Eclipse is not new to strange behavior,
but I wanted to know if anyone on the ML has a nice answer, solution or
workaround (other than standard answers like "use another IDE"), or at
least experiences the same issue with the code.
Thank you,
Claudio
---
[1]
https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827&view=markup
[2] Multiple markers at this line
- Bound mismatch: The generic method applyingFordFulkerson(OM) of
type MaxFlowAlgorithmSelector<V,W,WE,G> is not applicable for the
arguments (IntegerWeight). The
inferred type IntegerWeight is not a valid substitute for the
bounded parameter <OM extends OrderedMonoid<Object>>
- Type mismatch: cannot convert from Object to Integer
- Bound mismatch: The generic method findMaxFlow(G) of type
CommonsGraph<V,E,G> is not applicable for the arguments
(DirectedMutableWeightedGraph<BaseLabeledVertex,BaseLabeledWeightedEdge<Integer>,Integer>). The inferred type BaseLabeledWeightedEdge<Integer> is not a valid substitute
for the bounded parameter <WE extends WeightedEdge<W>>
--
Claudio Squarcella
PhD student at Roma Tre University
E-mail address: squarcel@dia.uniroma3.it
Phone: +39-06-57333215
Fax: +39-06-57333612
http://www.dia.uniroma3.it/~squarcel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
On 26/01/2012 18:05, Matt Benson wrote:
> On Thu, Jan 26, 2012 at 11:01 AM, Simone Tripodi
> <si...@apache.org> wrote:
>> FIXED!!!!
>>
>> Emanuele Lombardi, a former colleague of mine, simply did
>>
>> - public static<V extends Vertex, W, WE extends WeightedEdge<W>, G
>> extends Graph<V, WE>> SpanningTreeSourceSelector<V, W, WE, G>
>> minimumSpanningTree( G graph )
>> + public static<V extends Vertex, WE extends WeightedEdge<W>, W, G
>> extends Graph<V, WE>> SpanningTreeSourceSelector<V, W, WE, G>
>> minimumSpanningTree( G graph )
>>
>> and it makes it working!!!!
>> Isn't that cool?
> Hmm... doesn't seem to be working here on:
>
> Eclipse Platform
>
> Version: 3.7.1
> Build id: M20110909-1335
same here. Maybe with another bit of tweaking like that (although that
sounds a bit non-deterministic...)
Claudio
>
> Matt :|
>
>> All the best!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Thu, Jan 26, 2012 at 5:25 PM, Simone Tripodi
>> <si...@apache.org> wrote:
>>> Terrific feedbacks - like always! - Matt, thanks a lot, very appreciated!!!
>>> We do - at least, I - love you! :D
>>>
>>>> on. I can only surmise that the Oracle (?) compiler may take the
>>>> subsequent method calls into account when trying to infer type
>>>> parameters from arguments, perhaps.
>>> I am using the Apple's JDK:
>>>
>>> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
>>> Maven home: /Applications/apache-maven-3.0.4
>>> Java version: 1.6.0_29, vendor: Apple Inc.
>>> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
>>> Default locale: en_US, platform encoding: MacRoman
>>> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>>>
>>>> however one thing that springs to mind is to take the
>>>> CommonsGraph fluent APIs and move them to some typed interface, then
>>>> have each level of the interface hierarchy define a public static
>>>> final instance of this fluent interface that knows how to behave
>>>> appropriately for that type...? Not sure if this would work properly
>>>> in practice, but the best idea I'm likely to come up with.
>>> this is what I tried to do indeed, CommonsGraph#findMaxFlow returns an
>>> interface where generic types are inferred depending on the graph
>>> input.
>>>
>>> Thanks *a lot* for your kind help, always much more than appreciated!!!
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Thu, Jan 26, 2012 at 5:08 PM, Matt Benson<gu...@gmail.com> wrote:
>>>> Whew... I hope you guys love me. :P I decided to take a look just
>>>> because I've had to play with Eclipse before on issues like this.
>>>> What I typically find is that Eclipse has a sane reason for
>>>> complaining where it does. This time I *really* thought Eclipse was
>>>> wrong... but check this out:
>>>>
>>>> In the FordFulkersonTestCase, if you break this down statement by
>>>> statement, what Eclipse is complaining about is "findMaxFlow(graph);".
>>>> Now, if you use Eclipse's 'Assign to local variable' quick assist,
>>>> you find that it creates a variable of type:
>>>>
>>>> FromHeadBuilder<BaseLabeledVertex, Object,
>>>> BaseLabeledWeightedEdge<Integer>,
>>>> DirectedMutableWeightedGraph<BaseLabeledVertex,
>>>> BaseLabeledWeightedEdge<Integer>, Integer>>
>>>>
>>>> Note that it has calculated the W type parameter to be Object.
>>>>
>>>> I am reasonably sure that the reason for this is that
>>>> CommonsGraph.findMaxFlow's<G> type parameter is declared as "G
>>>> extends DirectedGraph<V, WE>". Thus the fact that our
>>>> DirectedMutableWeightedGraph 'graph' has its W type parameter assigned
>>>> as Integer is completely irrelevant as far as #findMaxFlow() is
>>>> concerned. There is no way for the compiler to infer that
>>>> #findMaxFlow<W> should be Integer in the context of the fully chained
>>>> call. By contrast, simply changing Object to Integer in the signature
>>>> of Eclipse's generated local variable gives the compiler enough to go
>>>> on. I can only surmise that the Oracle (?) compiler may take the
>>>> subsequent method calls into account when trying to infer type
>>>> parameters from arguments, perhaps.
>>>>
>>>> So that's my diagnosis. How to cope with it while retaining fluency
>>>> is another story. I'm not familiar enough with the domain or the API
>>>> to be able to make any recommendation that would probably be terribly
>>>> useful; however one thing that springs to mind is to take the
>>>> CommonsGraph fluent APIs and move them to some typed interface, then
>>>> have each level of the interface hierarchy define a public static
>>>> final instance of this fluent interface that knows how to behave
>>>> appropriately for that type...? Not sure if this would work properly
>>>> in practice, but the best idea I'm likely to come up with.
>>>>
>>>> HTH,
>>>> Matt
>>>>
>>>> On Thu, Jan 26, 2012 at 8:42 AM, Simone Tripodi
>>>> <si...@apache.org> wrote:
>>>>> Hi Claudio!!!
>>>>>
>>>>> thanks for reporting, I have indeed the same issue - even if I thought
>>>>> was just an Eclipse bug!
>>>>> I honestly don't know how to fix the problem, I hope someone in the ML
>>>>> can provide a solution as well - same behavior met in IntelliJ!!!
>>>>>
>>>>> All the best,
>>>>> -Simo
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://simonetripodi.livejournal.com/
>>>>> http://twitter.com/simonetripodi
>>>>> http://www.99soft.org/
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 26, 2012 at 3:33 PM, Claudio Squarcella
>>>>> <sq...@dia.uniroma3.it> wrote:
>>>>>> P.S. for completeness:
>>>>>>
>>>>>> Eclipse version: Indigo Service Release 1
>>>>>> Build id: 20110916-0149
>>>>>> OS: Mac OS X Lion
>>>>>>
>>>>>> Cheers,
>>>>>> Claudio
>>>>>>
>>>>>>
>>>>>> On 26/01/2012 15:30, Claudio Squarcella wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I am experiencing a rather annoying issue with the latest version of
>>>>>>> commons-graph on Eclipse. Compiling with javac (maven, command line) it
>>>>>>> works fine, but the editor still complains: e.g. line 72 of the new
>>>>>>> FordFulkersonTestCase[1] gives a list of errors[2].
>>>>>>>
>>>>>>> Now, I know from googling that Eclipse is not new to strange behavior, but
>>>>>>> I wanted to know if anyone on the ML has a nice answer, solution or
>>>>>>> workaround (other than standard answers like "use another IDE"), or at least
>>>>>>> experiences the same issue with the code.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Claudio
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> [1]
>>>>>>> https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827&view=markup
>>>>>>> [2] Multiple markers at this line
>>>>>>> - Bound mismatch: The generic method applyingFordFulkerson(OM) of type
>>>>>>> MaxFlowAlgorithmSelector<V,W,WE,G> is not applicable for the arguments
>>>>>>> (IntegerWeight). The
>>>>>>> inferred type IntegerWeight is not a valid substitute for the bounded
>>>>>>> parameter<OM extends OrderedMonoid<Object>>
>>>>>>> - Type mismatch: cannot convert from Object to Integer
>>>>>>> - Bound mismatch: The generic method findMaxFlow(G) of type
>>>>>>> CommonsGraph<V,E,G> is not applicable for the arguments
>>>>>>>
>>>>>>> (DirectedMutableWeightedGraph<BaseLabeledVertex,BaseLabeledWeightedEdge<Integer>,Integer>).
>>>>>>> The inferred type BaseLabeledWeightedEdge<Integer> is not a valid substitute
>>>>>>> for the bounded parameter<WE extends WeightedEdge<W>>
>>>>>>>
>>>>>> --
>>>>>> Claudio Squarcella
>>>>>> PhD student at Roma Tre University
>>>>>> E-mail address: squarcel@dia.uniroma3.it
>>>>>> Phone: +39-06-57333215
>>>>>> Fax: +39-06-57333612
>>>>>> http://www.dia.uniroma3.it/~squarcel
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Claudio Squarcella
PhD student at Roma Tre University
E-mail address: squarcel@dia.uniroma3.it
Phone: +39-06-57333215
Fax: +39-06-57333612
http://www.dia.uniroma3.it/~squarcel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
Posted by Simone Tripodi <si...@apache.org>.
ouch :( :(
I suspect the trick just works on IntelliJ... ;(
thanks for the feedbacks!!!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Jan 26, 2012 at 6:05 PM, Matt Benson <gu...@gmail.com> wrote:
> On Thu, Jan 26, 2012 at 11:01 AM, Simone Tripodi
> <si...@apache.org> wrote:
>> FIXED!!!!
>>
>> Emanuele Lombardi, a former colleague of mine, simply did
>>
>> - public static <V extends Vertex, W, WE extends WeightedEdge<W>, G
>> extends Graph<V, WE>> SpanningTreeSourceSelector<V, W, WE, G>
>> minimumSpanningTree( G graph )
>> + public static <V extends Vertex, WE extends WeightedEdge<W>, W, G
>> extends Graph<V, WE>> SpanningTreeSourceSelector<V, W, WE, G>
>> minimumSpanningTree( G graph )
>>
>> and it makes it working!!!!
>> Isn't that cool?
>
> Hmm... doesn't seem to be working here on:
>
> Eclipse Platform
>
> Version: 3.7.1
> Build id: M20110909-1335
>
> Matt :|
>
>> All the best!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Thu, Jan 26, 2012 at 5:25 PM, Simone Tripodi
>> <si...@apache.org> wrote:
>>> Terrific feedbacks - like always! - Matt, thanks a lot, very appreciated!!!
>>> We do - at least, I - love you! :D
>>>
>>>> on. I can only surmise that the Oracle (?) compiler may take the
>>>> subsequent method calls into account when trying to infer type
>>>> parameters from arguments, perhaps.
>>>
>>> I am using the Apple's JDK:
>>>
>>> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
>>> Maven home: /Applications/apache-maven-3.0.4
>>> Java version: 1.6.0_29, vendor: Apple Inc.
>>> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
>>> Default locale: en_US, platform encoding: MacRoman
>>> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>>>
>>>> however one thing that springs to mind is to take the
>>>> CommonsGraph fluent APIs and move them to some typed interface, then
>>>> have each level of the interface hierarchy define a public static
>>>> final instance of this fluent interface that knows how to behave
>>>> appropriately for that type...? Not sure if this would work properly
>>>> in practice, but the best idea I'm likely to come up with.
>>>
>>> this is what I tried to do indeed, CommonsGraph#findMaxFlow returns an
>>> interface where generic types are inferred depending on the graph
>>> input.
>>>
>>> Thanks *a lot* for your kind help, always much more than appreciated!!!
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Thu, Jan 26, 2012 at 5:08 PM, Matt Benson <gu...@gmail.com> wrote:
>>>> Whew... I hope you guys love me. :P I decided to take a look just
>>>> because I've had to play with Eclipse before on issues like this.
>>>> What I typically find is that Eclipse has a sane reason for
>>>> complaining where it does. This time I *really* thought Eclipse was
>>>> wrong... but check this out:
>>>>
>>>> In the FordFulkersonTestCase, if you break this down statement by
>>>> statement, what Eclipse is complaining about is "findMaxFlow(graph);".
>>>> Now, if you use Eclipse's 'Assign to local variable' quick assist,
>>>> you find that it creates a variable of type:
>>>>
>>>> FromHeadBuilder<BaseLabeledVertex, Object,
>>>> BaseLabeledWeightedEdge<Integer>,
>>>> DirectedMutableWeightedGraph<BaseLabeledVertex,
>>>> BaseLabeledWeightedEdge<Integer>, Integer>>
>>>>
>>>> Note that it has calculated the W type parameter to be Object.
>>>>
>>>> I am reasonably sure that the reason for this is that
>>>> CommonsGraph.findMaxFlow's <G> type parameter is declared as "G
>>>> extends DirectedGraph<V, WE>". Thus the fact that our
>>>> DirectedMutableWeightedGraph 'graph' has its W type parameter assigned
>>>> as Integer is completely irrelevant as far as #findMaxFlow() is
>>>> concerned. There is no way for the compiler to infer that
>>>> #findMaxFlow<W> should be Integer in the context of the fully chained
>>>> call. By contrast, simply changing Object to Integer in the signature
>>>> of Eclipse's generated local variable gives the compiler enough to go
>>>> on. I can only surmise that the Oracle (?) compiler may take the
>>>> subsequent method calls into account when trying to infer type
>>>> parameters from arguments, perhaps.
>>>>
>>>> So that's my diagnosis. How to cope with it while retaining fluency
>>>> is another story. I'm not familiar enough with the domain or the API
>>>> to be able to make any recommendation that would probably be terribly
>>>> useful; however one thing that springs to mind is to take the
>>>> CommonsGraph fluent APIs and move them to some typed interface, then
>>>> have each level of the interface hierarchy define a public static
>>>> final instance of this fluent interface that knows how to behave
>>>> appropriately for that type...? Not sure if this would work properly
>>>> in practice, but the best idea I'm likely to come up with.
>>>>
>>>> HTH,
>>>> Matt
>>>>
>>>> On Thu, Jan 26, 2012 at 8:42 AM, Simone Tripodi
>>>> <si...@apache.org> wrote:
>>>>> Hi Claudio!!!
>>>>>
>>>>> thanks for reporting, I have indeed the same issue - even if I thought
>>>>> was just an Eclipse bug!
>>>>> I honestly don't know how to fix the problem, I hope someone in the ML
>>>>> can provide a solution as well - same behavior met in IntelliJ!!!
>>>>>
>>>>> All the best,
>>>>> -Simo
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://simonetripodi.livejournal.com/
>>>>> http://twitter.com/simonetripodi
>>>>> http://www.99soft.org/
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 26, 2012 at 3:33 PM, Claudio Squarcella
>>>>> <sq...@dia.uniroma3.it> wrote:
>>>>>> P.S. for completeness:
>>>>>>
>>>>>> Eclipse version: Indigo Service Release 1
>>>>>> Build id: 20110916-0149
>>>>>> OS: Mac OS X Lion
>>>>>>
>>>>>> Cheers,
>>>>>> Claudio
>>>>>>
>>>>>>
>>>>>> On 26/01/2012 15:30, Claudio Squarcella wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I am experiencing a rather annoying issue with the latest version of
>>>>>>> commons-graph on Eclipse. Compiling with javac (maven, command line) it
>>>>>>> works fine, but the editor still complains: e.g. line 72 of the new
>>>>>>> FordFulkersonTestCase[1] gives a list of errors[2].
>>>>>>>
>>>>>>> Now, I know from googling that Eclipse is not new to strange behavior, but
>>>>>>> I wanted to know if anyone on the ML has a nice answer, solution or
>>>>>>> workaround (other than standard answers like "use another IDE"), or at least
>>>>>>> experiences the same issue with the code.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Claudio
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> [1]
>>>>>>> https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827&view=markup
>>>>>>> [2] Multiple markers at this line
>>>>>>> - Bound mismatch: The generic method applyingFordFulkerson(OM) of type
>>>>>>> MaxFlowAlgorithmSelector<V,W,WE,G> is not applicable for the arguments
>>>>>>> (IntegerWeight). The
>>>>>>> inferred type IntegerWeight is not a valid substitute for the bounded
>>>>>>> parameter <OM extends OrderedMonoid<Object>>
>>>>>>> - Type mismatch: cannot convert from Object to Integer
>>>>>>> - Bound mismatch: The generic method findMaxFlow(G) of type
>>>>>>> CommonsGraph<V,E,G> is not applicable for the arguments
>>>>>>>
>>>>>>> (DirectedMutableWeightedGraph<BaseLabeledVertex,BaseLabeledWeightedEdge<Integer>,Integer>).
>>>>>>> The inferred type BaseLabeledWeightedEdge<Integer> is not a valid substitute
>>>>>>> for the bounded parameter <WE extends WeightedEdge<W>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Claudio Squarcella
>>>>>> PhD student at Roma Tre University
>>>>>> E-mail address: squarcel@dia.uniroma3.it
>>>>>> Phone: +39-06-57333215
>>>>>> Fax: +39-06-57333612
>>>>>> http://www.dia.uniroma3.it/~squarcel
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
Posted by Matt Benson <gu...@gmail.com>.
On Thu, Jan 26, 2012 at 11:01 AM, Simone Tripodi
<si...@apache.org> wrote:
> FIXED!!!!
>
> Emanuele Lombardi, a former colleague of mine, simply did
>
> - public static <V extends Vertex, W, WE extends WeightedEdge<W>, G
> extends Graph<V, WE>> SpanningTreeSourceSelector<V, W, WE, G>
> minimumSpanningTree( G graph )
> + public static <V extends Vertex, WE extends WeightedEdge<W>, W, G
> extends Graph<V, WE>> SpanningTreeSourceSelector<V, W, WE, G>
> minimumSpanningTree( G graph )
>
> and it makes it working!!!!
> Isn't that cool?
Hmm... doesn't seem to be working here on:
Eclipse Platform
Version: 3.7.1
Build id: M20110909-1335
Matt :|
> All the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Thu, Jan 26, 2012 at 5:25 PM, Simone Tripodi
> <si...@apache.org> wrote:
>> Terrific feedbacks - like always! - Matt, thanks a lot, very appreciated!!!
>> We do - at least, I - love you! :D
>>
>>> on. I can only surmise that the Oracle (?) compiler may take the
>>> subsequent method calls into account when trying to infer type
>>> parameters from arguments, perhaps.
>>
>> I am using the Apple's JDK:
>>
>> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
>> Maven home: /Applications/apache-maven-3.0.4
>> Java version: 1.6.0_29, vendor: Apple Inc.
>> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
>> Default locale: en_US, platform encoding: MacRoman
>> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>>
>>> however one thing that springs to mind is to take the
>>> CommonsGraph fluent APIs and move them to some typed interface, then
>>> have each level of the interface hierarchy define a public static
>>> final instance of this fluent interface that knows how to behave
>>> appropriately for that type...? Not sure if this would work properly
>>> in practice, but the best idea I'm likely to come up with.
>>
>> this is what I tried to do indeed, CommonsGraph#findMaxFlow returns an
>> interface where generic types are inferred depending on the graph
>> input.
>>
>> Thanks *a lot* for your kind help, always much more than appreciated!!!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Thu, Jan 26, 2012 at 5:08 PM, Matt Benson <gu...@gmail.com> wrote:
>>> Whew... I hope you guys love me. :P I decided to take a look just
>>> because I've had to play with Eclipse before on issues like this.
>>> What I typically find is that Eclipse has a sane reason for
>>> complaining where it does. This time I *really* thought Eclipse was
>>> wrong... but check this out:
>>>
>>> In the FordFulkersonTestCase, if you break this down statement by
>>> statement, what Eclipse is complaining about is "findMaxFlow(graph);".
>>> Now, if you use Eclipse's 'Assign to local variable' quick assist,
>>> you find that it creates a variable of type:
>>>
>>> FromHeadBuilder<BaseLabeledVertex, Object,
>>> BaseLabeledWeightedEdge<Integer>,
>>> DirectedMutableWeightedGraph<BaseLabeledVertex,
>>> BaseLabeledWeightedEdge<Integer>, Integer>>
>>>
>>> Note that it has calculated the W type parameter to be Object.
>>>
>>> I am reasonably sure that the reason for this is that
>>> CommonsGraph.findMaxFlow's <G> type parameter is declared as "G
>>> extends DirectedGraph<V, WE>". Thus the fact that our
>>> DirectedMutableWeightedGraph 'graph' has its W type parameter assigned
>>> as Integer is completely irrelevant as far as #findMaxFlow() is
>>> concerned. There is no way for the compiler to infer that
>>> #findMaxFlow<W> should be Integer in the context of the fully chained
>>> call. By contrast, simply changing Object to Integer in the signature
>>> of Eclipse's generated local variable gives the compiler enough to go
>>> on. I can only surmise that the Oracle (?) compiler may take the
>>> subsequent method calls into account when trying to infer type
>>> parameters from arguments, perhaps.
>>>
>>> So that's my diagnosis. How to cope with it while retaining fluency
>>> is another story. I'm not familiar enough with the domain or the API
>>> to be able to make any recommendation that would probably be terribly
>>> useful; however one thing that springs to mind is to take the
>>> CommonsGraph fluent APIs and move them to some typed interface, then
>>> have each level of the interface hierarchy define a public static
>>> final instance of this fluent interface that knows how to behave
>>> appropriately for that type...? Not sure if this would work properly
>>> in practice, but the best idea I'm likely to come up with.
>>>
>>> HTH,
>>> Matt
>>>
>>> On Thu, Jan 26, 2012 at 8:42 AM, Simone Tripodi
>>> <si...@apache.org> wrote:
>>>> Hi Claudio!!!
>>>>
>>>> thanks for reporting, I have indeed the same issue - even if I thought
>>>> was just an Eclipse bug!
>>>> I honestly don't know how to fix the problem, I hope someone in the ML
>>>> can provide a solution as well - same behavior met in IntelliJ!!!
>>>>
>>>> All the best,
>>>> -Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Thu, Jan 26, 2012 at 3:33 PM, Claudio Squarcella
>>>> <sq...@dia.uniroma3.it> wrote:
>>>>> P.S. for completeness:
>>>>>
>>>>> Eclipse version: Indigo Service Release 1
>>>>> Build id: 20110916-0149
>>>>> OS: Mac OS X Lion
>>>>>
>>>>> Cheers,
>>>>> Claudio
>>>>>
>>>>>
>>>>> On 26/01/2012 15:30, Claudio Squarcella wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I am experiencing a rather annoying issue with the latest version of
>>>>>> commons-graph on Eclipse. Compiling with javac (maven, command line) it
>>>>>> works fine, but the editor still complains: e.g. line 72 of the new
>>>>>> FordFulkersonTestCase[1] gives a list of errors[2].
>>>>>>
>>>>>> Now, I know from googling that Eclipse is not new to strange behavior, but
>>>>>> I wanted to know if anyone on the ML has a nice answer, solution or
>>>>>> workaround (other than standard answers like "use another IDE"), or at least
>>>>>> experiences the same issue with the code.
>>>>>>
>>>>>> Thank you,
>>>>>> Claudio
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> [1]
>>>>>> https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827&view=markup
>>>>>> [2] Multiple markers at this line
>>>>>> - Bound mismatch: The generic method applyingFordFulkerson(OM) of type
>>>>>> MaxFlowAlgorithmSelector<V,W,WE,G> is not applicable for the arguments
>>>>>> (IntegerWeight). The
>>>>>> inferred type IntegerWeight is not a valid substitute for the bounded
>>>>>> parameter <OM extends OrderedMonoid<Object>>
>>>>>> - Type mismatch: cannot convert from Object to Integer
>>>>>> - Bound mismatch: The generic method findMaxFlow(G) of type
>>>>>> CommonsGraph<V,E,G> is not applicable for the arguments
>>>>>>
>>>>>> (DirectedMutableWeightedGraph<BaseLabeledVertex,BaseLabeledWeightedEdge<Integer>,Integer>).
>>>>>> The inferred type BaseLabeledWeightedEdge<Integer> is not a valid substitute
>>>>>> for the bounded parameter <WE extends WeightedEdge<W>>
>>>>>>
>>>>>
>>>>> --
>>>>> Claudio Squarcella
>>>>> PhD student at Roma Tre University
>>>>> E-mail address: squarcel@dia.uniroma3.it
>>>>> Phone: +39-06-57333215
>>>>> Fax: +39-06-57333612
>>>>> http://www.dia.uniroma3.it/~squarcel
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
Posted by Simone Tripodi <si...@apache.org>.
FIXED!!!!
Emanuele Lombardi, a former colleague of mine, simply did
- public static <V extends Vertex, W, WE extends WeightedEdge<W>, G
extends Graph<V, WE>> SpanningTreeSourceSelector<V, W, WE, G>
minimumSpanningTree( G graph )
+ public static <V extends Vertex, WE extends WeightedEdge<W>, W, G
extends Graph<V, WE>> SpanningTreeSourceSelector<V, W, WE, G>
minimumSpanningTree( G graph )
and it makes it working!!!!
Isn't that cool?
All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Jan 26, 2012 at 5:25 PM, Simone Tripodi
<si...@apache.org> wrote:
> Terrific feedbacks - like always! - Matt, thanks a lot, very appreciated!!!
> We do - at least, I - love you! :D
>
>> on. I can only surmise that the Oracle (?) compiler may take the
>> subsequent method calls into account when trying to infer type
>> parameters from arguments, perhaps.
>
> I am using the Apple's JDK:
>
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: /Applications/apache-maven-3.0.4
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>
>> however one thing that springs to mind is to take the
>> CommonsGraph fluent APIs and move them to some typed interface, then
>> have each level of the interface hierarchy define a public static
>> final instance of this fluent interface that knows how to behave
>> appropriately for that type...? Not sure if this would work properly
>> in practice, but the best idea I'm likely to come up with.
>
> this is what I tried to do indeed, CommonsGraph#findMaxFlow returns an
> interface where generic types are inferred depending on the graph
> input.
>
> Thanks *a lot* for your kind help, always much more than appreciated!!!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Thu, Jan 26, 2012 at 5:08 PM, Matt Benson <gu...@gmail.com> wrote:
>> Whew... I hope you guys love me. :P I decided to take a look just
>> because I've had to play with Eclipse before on issues like this.
>> What I typically find is that Eclipse has a sane reason for
>> complaining where it does. This time I *really* thought Eclipse was
>> wrong... but check this out:
>>
>> In the FordFulkersonTestCase, if you break this down statement by
>> statement, what Eclipse is complaining about is "findMaxFlow(graph);".
>> Now, if you use Eclipse's 'Assign to local variable' quick assist,
>> you find that it creates a variable of type:
>>
>> FromHeadBuilder<BaseLabeledVertex, Object,
>> BaseLabeledWeightedEdge<Integer>,
>> DirectedMutableWeightedGraph<BaseLabeledVertex,
>> BaseLabeledWeightedEdge<Integer>, Integer>>
>>
>> Note that it has calculated the W type parameter to be Object.
>>
>> I am reasonably sure that the reason for this is that
>> CommonsGraph.findMaxFlow's <G> type parameter is declared as "G
>> extends DirectedGraph<V, WE>". Thus the fact that our
>> DirectedMutableWeightedGraph 'graph' has its W type parameter assigned
>> as Integer is completely irrelevant as far as #findMaxFlow() is
>> concerned. There is no way for the compiler to infer that
>> #findMaxFlow<W> should be Integer in the context of the fully chained
>> call. By contrast, simply changing Object to Integer in the signature
>> of Eclipse's generated local variable gives the compiler enough to go
>> on. I can only surmise that the Oracle (?) compiler may take the
>> subsequent method calls into account when trying to infer type
>> parameters from arguments, perhaps.
>>
>> So that's my diagnosis. How to cope with it while retaining fluency
>> is another story. I'm not familiar enough with the domain or the API
>> to be able to make any recommendation that would probably be terribly
>> useful; however one thing that springs to mind is to take the
>> CommonsGraph fluent APIs and move them to some typed interface, then
>> have each level of the interface hierarchy define a public static
>> final instance of this fluent interface that knows how to behave
>> appropriately for that type...? Not sure if this would work properly
>> in practice, but the best idea I'm likely to come up with.
>>
>> HTH,
>> Matt
>>
>> On Thu, Jan 26, 2012 at 8:42 AM, Simone Tripodi
>> <si...@apache.org> wrote:
>>> Hi Claudio!!!
>>>
>>> thanks for reporting, I have indeed the same issue - even if I thought
>>> was just an Eclipse bug!
>>> I honestly don't know how to fix the problem, I hope someone in the ML
>>> can provide a solution as well - same behavior met in IntelliJ!!!
>>>
>>> All the best,
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Thu, Jan 26, 2012 at 3:33 PM, Claudio Squarcella
>>> <sq...@dia.uniroma3.it> wrote:
>>>> P.S. for completeness:
>>>>
>>>> Eclipse version: Indigo Service Release 1
>>>> Build id: 20110916-0149
>>>> OS: Mac OS X Lion
>>>>
>>>> Cheers,
>>>> Claudio
>>>>
>>>>
>>>> On 26/01/2012 15:30, Claudio Squarcella wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I am experiencing a rather annoying issue with the latest version of
>>>>> commons-graph on Eclipse. Compiling with javac (maven, command line) it
>>>>> works fine, but the editor still complains: e.g. line 72 of the new
>>>>> FordFulkersonTestCase[1] gives a list of errors[2].
>>>>>
>>>>> Now, I know from googling that Eclipse is not new to strange behavior, but
>>>>> I wanted to know if anyone on the ML has a nice answer, solution or
>>>>> workaround (other than standard answers like "use another IDE"), or at least
>>>>> experiences the same issue with the code.
>>>>>
>>>>> Thank you,
>>>>> Claudio
>>>>>
>>>>> ---
>>>>>
>>>>> [1]
>>>>> https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827&view=markup
>>>>> [2] Multiple markers at this line
>>>>> - Bound mismatch: The generic method applyingFordFulkerson(OM) of type
>>>>> MaxFlowAlgorithmSelector<V,W,WE,G> is not applicable for the arguments
>>>>> (IntegerWeight). The
>>>>> inferred type IntegerWeight is not a valid substitute for the bounded
>>>>> parameter <OM extends OrderedMonoid<Object>>
>>>>> - Type mismatch: cannot convert from Object to Integer
>>>>> - Bound mismatch: The generic method findMaxFlow(G) of type
>>>>> CommonsGraph<V,E,G> is not applicable for the arguments
>>>>>
>>>>> (DirectedMutableWeightedGraph<BaseLabeledVertex,BaseLabeledWeightedEdge<Integer>,Integer>).
>>>>> The inferred type BaseLabeledWeightedEdge<Integer> is not a valid substitute
>>>>> for the bounded parameter <WE extends WeightedEdge<W>>
>>>>>
>>>>
>>>> --
>>>> Claudio Squarcella
>>>> PhD student at Roma Tre University
>>>> E-mail address: squarcel@dia.uniroma3.it
>>>> Phone: +39-06-57333215
>>>> Fax: +39-06-57333612
>>>> http://www.dia.uniroma3.it/~squarcel
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
Posted by Simone Tripodi <si...@apache.org>.
Terrific feedbacks - like always! - Matt, thanks a lot, very appreciated!!!
We do - at least, I - love you! :D
> on. I can only surmise that the Oracle (?) compiler may take the
> subsequent method calls into account when trying to infer type
> parameters from arguments, perhaps.
I am using the Apple's JDK:
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /Applications/apache-maven-3.0.4
Java version: 1.6.0_29, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
> however one thing that springs to mind is to take the
> CommonsGraph fluent APIs and move them to some typed interface, then
> have each level of the interface hierarchy define a public static
> final instance of this fluent interface that knows how to behave
> appropriately for that type...? Not sure if this would work properly
> in practice, but the best idea I'm likely to come up with.
this is what I tried to do indeed, CommonsGraph#findMaxFlow returns an
interface where generic types are inferred depending on the graph
input.
Thanks *a lot* for your kind help, always much more than appreciated!!!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Jan 26, 2012 at 5:08 PM, Matt Benson <gu...@gmail.com> wrote:
> Whew... I hope you guys love me. :P I decided to take a look just
> because I've had to play with Eclipse before on issues like this.
> What I typically find is that Eclipse has a sane reason for
> complaining where it does. This time I *really* thought Eclipse was
> wrong... but check this out:
>
> In the FordFulkersonTestCase, if you break this down statement by
> statement, what Eclipse is complaining about is "findMaxFlow(graph);".
> Now, if you use Eclipse's 'Assign to local variable' quick assist,
> you find that it creates a variable of type:
>
> FromHeadBuilder<BaseLabeledVertex, Object,
> BaseLabeledWeightedEdge<Integer>,
> DirectedMutableWeightedGraph<BaseLabeledVertex,
> BaseLabeledWeightedEdge<Integer>, Integer>>
>
> Note that it has calculated the W type parameter to be Object.
>
> I am reasonably sure that the reason for this is that
> CommonsGraph.findMaxFlow's <G> type parameter is declared as "G
> extends DirectedGraph<V, WE>". Thus the fact that our
> DirectedMutableWeightedGraph 'graph' has its W type parameter assigned
> as Integer is completely irrelevant as far as #findMaxFlow() is
> concerned. There is no way for the compiler to infer that
> #findMaxFlow<W> should be Integer in the context of the fully chained
> call. By contrast, simply changing Object to Integer in the signature
> of Eclipse's generated local variable gives the compiler enough to go
> on. I can only surmise that the Oracle (?) compiler may take the
> subsequent method calls into account when trying to infer type
> parameters from arguments, perhaps.
>
> So that's my diagnosis. How to cope with it while retaining fluency
> is another story. I'm not familiar enough with the domain or the API
> to be able to make any recommendation that would probably be terribly
> useful; however one thing that springs to mind is to take the
> CommonsGraph fluent APIs and move them to some typed interface, then
> have each level of the interface hierarchy define a public static
> final instance of this fluent interface that knows how to behave
> appropriately for that type...? Not sure if this would work properly
> in practice, but the best idea I'm likely to come up with.
>
> HTH,
> Matt
>
> On Thu, Jan 26, 2012 at 8:42 AM, Simone Tripodi
> <si...@apache.org> wrote:
>> Hi Claudio!!!
>>
>> thanks for reporting, I have indeed the same issue - even if I thought
>> was just an Eclipse bug!
>> I honestly don't know how to fix the problem, I hope someone in the ML
>> can provide a solution as well - same behavior met in IntelliJ!!!
>>
>> All the best,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Thu, Jan 26, 2012 at 3:33 PM, Claudio Squarcella
>> <sq...@dia.uniroma3.it> wrote:
>>> P.S. for completeness:
>>>
>>> Eclipse version: Indigo Service Release 1
>>> Build id: 20110916-0149
>>> OS: Mac OS X Lion
>>>
>>> Cheers,
>>> Claudio
>>>
>>>
>>> On 26/01/2012 15:30, Claudio Squarcella wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I am experiencing a rather annoying issue with the latest version of
>>>> commons-graph on Eclipse. Compiling with javac (maven, command line) it
>>>> works fine, but the editor still complains: e.g. line 72 of the new
>>>> FordFulkersonTestCase[1] gives a list of errors[2].
>>>>
>>>> Now, I know from googling that Eclipse is not new to strange behavior, but
>>>> I wanted to know if anyone on the ML has a nice answer, solution or
>>>> workaround (other than standard answers like "use another IDE"), or at least
>>>> experiences the same issue with the code.
>>>>
>>>> Thank you,
>>>> Claudio
>>>>
>>>> ---
>>>>
>>>> [1]
>>>> https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827&view=markup
>>>> [2] Multiple markers at this line
>>>> - Bound mismatch: The generic method applyingFordFulkerson(OM) of type
>>>> MaxFlowAlgorithmSelector<V,W,WE,G> is not applicable for the arguments
>>>> (IntegerWeight). The
>>>> inferred type IntegerWeight is not a valid substitute for the bounded
>>>> parameter <OM extends OrderedMonoid<Object>>
>>>> - Type mismatch: cannot convert from Object to Integer
>>>> - Bound mismatch: The generic method findMaxFlow(G) of type
>>>> CommonsGraph<V,E,G> is not applicable for the arguments
>>>>
>>>> (DirectedMutableWeightedGraph<BaseLabeledVertex,BaseLabeledWeightedEdge<Integer>,Integer>).
>>>> The inferred type BaseLabeledWeightedEdge<Integer> is not a valid substitute
>>>> for the bounded parameter <WE extends WeightedEdge<W>>
>>>>
>>>
>>> --
>>> Claudio Squarcella
>>> PhD student at Roma Tre University
>>> E-mail address: squarcel@dia.uniroma3.it
>>> Phone: +39-06-57333215
>>> Fax: +39-06-57333612
>>> http://www.dia.uniroma3.it/~squarcel
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
Posted by Matt Benson <gu...@gmail.com>.
Whew... I hope you guys love me. :P I decided to take a look just
because I've had to play with Eclipse before on issues like this.
What I typically find is that Eclipse has a sane reason for
complaining where it does. This time I *really* thought Eclipse was
wrong... but check this out:
In the FordFulkersonTestCase, if you break this down statement by
statement, what Eclipse is complaining about is "findMaxFlow(graph);".
Now, if you use Eclipse's 'Assign to local variable' quick assist,
you find that it creates a variable of type:
FromHeadBuilder<BaseLabeledVertex, Object,
BaseLabeledWeightedEdge<Integer>,
DirectedMutableWeightedGraph<BaseLabeledVertex,
BaseLabeledWeightedEdge<Integer>, Integer>>
Note that it has calculated the W type parameter to be Object.
I am reasonably sure that the reason for this is that
CommonsGraph.findMaxFlow's <G> type parameter is declared as "G
extends DirectedGraph<V, WE>". Thus the fact that our
DirectedMutableWeightedGraph 'graph' has its W type parameter assigned
as Integer is completely irrelevant as far as #findMaxFlow() is
concerned. There is no way for the compiler to infer that
#findMaxFlow<W> should be Integer in the context of the fully chained
call. By contrast, simply changing Object to Integer in the signature
of Eclipse's generated local variable gives the compiler enough to go
on. I can only surmise that the Oracle (?) compiler may take the
subsequent method calls into account when trying to infer type
parameters from arguments, perhaps.
So that's my diagnosis. How to cope with it while retaining fluency
is another story. I'm not familiar enough with the domain or the API
to be able to make any recommendation that would probably be terribly
useful; however one thing that springs to mind is to take the
CommonsGraph fluent APIs and move them to some typed interface, then
have each level of the interface hierarchy define a public static
final instance of this fluent interface that knows how to behave
appropriately for that type...? Not sure if this would work properly
in practice, but the best idea I'm likely to come up with.
HTH,
Matt
On Thu, Jan 26, 2012 at 8:42 AM, Simone Tripodi
<si...@apache.org> wrote:
> Hi Claudio!!!
>
> thanks for reporting, I have indeed the same issue - even if I thought
> was just an Eclipse bug!
> I honestly don't know how to fix the problem, I hope someone in the ML
> can provide a solution as well - same behavior met in IntelliJ!!!
>
> All the best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Thu, Jan 26, 2012 at 3:33 PM, Claudio Squarcella
> <sq...@dia.uniroma3.it> wrote:
>> P.S. for completeness:
>>
>> Eclipse version: Indigo Service Release 1
>> Build id: 20110916-0149
>> OS: Mac OS X Lion
>>
>> Cheers,
>> Claudio
>>
>>
>> On 26/01/2012 15:30, Claudio Squarcella wrote:
>>>
>>> Hi all,
>>>
>>> I am experiencing a rather annoying issue with the latest version of
>>> commons-graph on Eclipse. Compiling with javac (maven, command line) it
>>> works fine, but the editor still complains: e.g. line 72 of the new
>>> FordFulkersonTestCase[1] gives a list of errors[2].
>>>
>>> Now, I know from googling that Eclipse is not new to strange behavior, but
>>> I wanted to know if anyone on the ML has a nice answer, solution or
>>> workaround (other than standard answers like "use another IDE"), or at least
>>> experiences the same issue with the code.
>>>
>>> Thank you,
>>> Claudio
>>>
>>> ---
>>>
>>> [1]
>>> https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827&view=markup
>>> [2] Multiple markers at this line
>>> - Bound mismatch: The generic method applyingFordFulkerson(OM) of type
>>> MaxFlowAlgorithmSelector<V,W,WE,G> is not applicable for the arguments
>>> (IntegerWeight). The
>>> inferred type IntegerWeight is not a valid substitute for the bounded
>>> parameter <OM extends OrderedMonoid<Object>>
>>> - Type mismatch: cannot convert from Object to Integer
>>> - Bound mismatch: The generic method findMaxFlow(G) of type
>>> CommonsGraph<V,E,G> is not applicable for the arguments
>>>
>>> (DirectedMutableWeightedGraph<BaseLabeledVertex,BaseLabeledWeightedEdge<Integer>,Integer>).
>>> The inferred type BaseLabeledWeightedEdge<Integer> is not a valid substitute
>>> for the bounded parameter <WE extends WeightedEdge<W>>
>>>
>>
>> --
>> Claudio Squarcella
>> PhD student at Roma Tre University
>> E-mail address: squarcel@dia.uniroma3.it
>> Phone: +39-06-57333215
>> Fax: +39-06-57333612
>> http://www.dia.uniroma3.it/~squarcel
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
Posted by Simone Tripodi <si...@apache.org>.
Hi Claudio!!!
thanks for reporting, I have indeed the same issue - even if I thought
was just an Eclipse bug!
I honestly don't know how to fix the problem, I hope someone in the ML
can provide a solution as well - same behavior met in IntelliJ!!!
All the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Jan 26, 2012 at 3:33 PM, Claudio Squarcella
<sq...@dia.uniroma3.it> wrote:
> P.S. for completeness:
>
> Eclipse version: Indigo Service Release 1
> Build id: 20110916-0149
> OS: Mac OS X Lion
>
> Cheers,
> Claudio
>
>
> On 26/01/2012 15:30, Claudio Squarcella wrote:
>>
>> Hi all,
>>
>> I am experiencing a rather annoying issue with the latest version of
>> commons-graph on Eclipse. Compiling with javac (maven, command line) it
>> works fine, but the editor still complains: e.g. line 72 of the new
>> FordFulkersonTestCase[1] gives a list of errors[2].
>>
>> Now, I know from googling that Eclipse is not new to strange behavior, but
>> I wanted to know if anyone on the ML has a nice answer, solution or
>> workaround (other than standard answers like "use another IDE"), or at least
>> experiences the same issue with the code.
>>
>> Thank you,
>> Claudio
>>
>> ---
>>
>> [1]
>> https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827&view=markup
>> [2] Multiple markers at this line
>> - Bound mismatch: The generic method applyingFordFulkerson(OM) of type
>> MaxFlowAlgorithmSelector<V,W,WE,G> is not applicable for the arguments
>> (IntegerWeight). The
>> inferred type IntegerWeight is not a valid substitute for the bounded
>> parameter <OM extends OrderedMonoid<Object>>
>> - Type mismatch: cannot convert from Object to Integer
>> - Bound mismatch: The generic method findMaxFlow(G) of type
>> CommonsGraph<V,E,G> is not applicable for the arguments
>>
>> (DirectedMutableWeightedGraph<BaseLabeledVertex,BaseLabeledWeightedEdge<Integer>,Integer>).
>> The inferred type BaseLabeledWeightedEdge<Integer> is not a valid substitute
>> for the bounded parameter <WE extends WeightedEdge<W>>
>>
>
> --
> Claudio Squarcella
> PhD student at Roma Tre University
> E-mail address: squarcel@dia.uniroma3.it
> Phone: +39-06-57333215
> Fax: +39-06-57333612
> http://www.dia.uniroma3.it/~squarcel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
P.S. for completeness:
Eclipse version: Indigo Service Release 1
Build id: 20110916-0149
OS: Mac OS X Lion
Cheers,
Claudio
On 26/01/2012 15:30, Claudio Squarcella wrote:
> Hi all,
>
> I am experiencing a rather annoying issue with the latest version of
> commons-graph on Eclipse. Compiling with javac (maven, command line)
> it works fine, but the editor still complains: e.g. line 72 of the new
> FordFulkersonTestCase[1] gives a list of errors[2].
>
> Now, I know from googling that Eclipse is not new to strange behavior,
> but I wanted to know if anyone on the ML has a nice answer, solution
> or workaround (other than standard answers like "use another IDE"), or
> at least experiences the same issue with the code.
>
> Thank you,
> Claudio
>
> ---
>
> [1]
> https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827&view=markup
> [2] Multiple markers at this line
> - Bound mismatch: The generic method applyingFordFulkerson(OM) of
> type MaxFlowAlgorithmSelector<V,W,WE,G> is not applicable for the
> arguments (IntegerWeight). The
> inferred type IntegerWeight is not a valid substitute for the
> bounded parameter <OM extends OrderedMonoid<Object>>
> - Type mismatch: cannot convert from Object to Integer
> - Bound mismatch: The generic method findMaxFlow(G) of type
> CommonsGraph<V,E,G> is not applicable for the arguments
>
> (DirectedMutableWeightedGraph<BaseLabeledVertex,BaseLabeledWeightedEdge<Integer>,Integer>).
> The inferred type BaseLabeledWeightedEdge<Integer> is not a valid
> substitute
> for the bounded parameter <WE extends WeightedEdge<W>>
>
--
Claudio Squarcella
PhD student at Roma Tre University
E-mail address: squarcel@dia.uniroma3.it
Phone: +39-06-57333215
Fax: +39-06-57333612
http://www.dia.uniroma3.it/~squarcel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org