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 <gudnabr...@gmail.com> wrote: > On Thu, Jan 26, 2012 at 11:01 AM, Simone Tripodi > <simonetrip...@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 >> <simonetrip...@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 <gudnabr...@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 >>>> <simonetrip...@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 >>>>> <squar...@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: squar...@dia.uniroma3.it >>>>>> Phone: +39-06-57333215 >>>>>> Fax: +39-06-57333612 >>>>>> http://www.dia.uniroma3.it/~squarcel >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
