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