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
