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