[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 is not applicable for the arguments (IntegerWeight). The inferred type IntegerWeight is not a valid substitute for the bounded parameter > - Type mismatch: cannot convert from Object to Integer - Bound mismatch: The generic method findMaxFlow(G) of type CommonsGraph is not applicable for the arguments (DirectedMutableWeightedGraph,Integer>). The inferred type BaseLabeledWeightedEdge is not a valid substitute for the bounded parameter > -- 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
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
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 is not applicable for the arguments (IntegerWeight). The inferred type IntegerWeight is not a valid substitute for the bounded parameter > - Type mismatch: cannot convert from Object to Integer - Bound mismatch: The generic method findMaxFlow(G) of type CommonsGraph is not applicable for the arguments (DirectedMutableWeightedGraph,Integer>). The inferred type BaseLabeledWeightedEdge is not a valid substitute for the bounded parameter > -- 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
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
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 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 is not applicable for the arguments >> (IntegerWeight). The >> inferred type IntegerWeight is not a valid substitute for the bounded >> parameter > >> - Type mismatch: cannot convert from Object to Integer >> - Bound mismatch: The generic method findMaxFlow(G) of type >> CommonsGraph is not applicable for the arguments >> >> (DirectedMutableWeightedGraph,Integer>). >> The inferred type BaseLabeledWeightedEdge is not a valid substitute >> for the bounded parameter > >> > > -- > 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
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
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, DirectedMutableWeightedGraph, 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 type parameter is declared as "G extends DirectedGraph". 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 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 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 > 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 is not applicable for the arguments >>> (IntegerWeight). The >>> inferred type IntegerWeight is not a valid substitute for the bounded >>> parameter > >>> - Type mismatch: cannot convert from Object to Integer >>> - Bound mismatch: The generic method findMaxFlow(G) of type >>> CommonsGraph is not applicable for the arguments >>> >>> (DirectedMutableWeightedGraph,Integer>). >>> The inferred type BaseLabeledWeightedEdge is not a valid substitute >>> for the bounded parameter > >>> >> >> -- >> 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.a
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
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 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 BaseLabeledWeightedEdge, > DirectedMutableWeightedGraph BaseLabeledWeightedEdge, 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 type parameter is declared as "G > extends DirectedGraph". 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 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 > 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 >> 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.
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
FIXED Emanuele Lombardi, a former colleague of mine, simply did -public static , G extends Graph> SpanningTreeSourceSelector minimumSpanningTree( G graph ) +public static , W, G extends Graph> SpanningTreeSourceSelector 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 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 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> BaseLabeledWeightedEdge, >> DirectedMutableWeightedGraph> BaseLabeledWeightedEdge, 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 type parameter is declared as "G >> extends DirectedGraph". 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 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 >> 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 >>> wrote: P.S. for completeness: Eclipse version: Indigo Service Release 1 Build id: 20110916-0149 OS: Mac OS X Lion Cheers, Claudio
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
On Thu, Jan 26, 2012 at 11:01 AM, Simone Tripodi wrote: > FIXED > > Emanuele Lombardi, a former colleague of mine, simply did > > - public static , G > extends Graph> SpanningTreeSourceSelector > minimumSpanningTree( G graph ) > + public static , W, G > extends Graph> SpanningTreeSourceSelector > 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 > 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 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>> BaseLabeledWeightedEdge, >>> DirectedMutableWeightedGraph>> BaseLabeledWeightedEdge, 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 type parameter is declared as "G >>> extends DirectedGraph". 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 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 >>> 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/ ht
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
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 wrote: > On Thu, Jan 26, 2012 at 11:01 AM, Simone Tripodi > wrote: >> FIXED >> >> Emanuele Lombardi, a former colleague of mine, simply did >> >> - public static , G >> extends Graph> SpanningTreeSourceSelector >> minimumSpanningTree( G graph ) >> + public static , W, G >> extends Graph> SpanningTreeSourceSelector >> 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 >> 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 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>>> BaseLabeledWeightedEdge, DirectedMutableWeightedGraph>>> BaseLabeledWeightedEdge, 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 type parameter is declared as "G extends DirectedGraph". 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 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 wrot
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
On 26/01/2012 18:05, Matt Benson wrote: On Thu, Jan 26, 2012 at 11:01 AM, Simone Tripodi wrote: FIXED Emanuele Lombardi, a former colleague of mine, simply did -public static, G extends Graph> SpanningTreeSourceSelector minimumSpanningTree( G graph ) +public static, W, G extends Graph> SpanningTreeSourceSelector 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 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 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, DirectedMutableWeightedGraph, 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 type parameter is declared as "G extends DirectedGraph". 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 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 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 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:
