[Neo] Issues with overloaded methods

Tobias Ivarsson thobes at gmail.com
Wed Apr 11 16:22:12 CEST 2007


On 4/11/07, Johan Svensson <johan at neopersistence.com> wrote:
>
> On 4/10/07, Tobias Ivarsson <thobes at gmail.com> wrote:
> >
> > Problem solved.
> >
> > I e-mailed the maintainer of JPype and told him about these problems.
> > The answer I got was that the CVS repository is broken and long dead. He
> > now
> > maintains the project on a personal svn system. (Yeah, very open source)
> > Then he gave me a snapshot from the last stable release.
> > Apparently they only distribute stable source packages these days, and
> the
> > last one (the one I tried first) was not UNIX compatable (windows only),
> > they had released a UNIX fix only yesterday.
> >
> > However. Neo4j.py works now. I will write some documentation and license
> > stuff and then publish it, and submit a link here so that anyone who is
> > interested may play with it.
>
>
> Well done and nice timing with the UNIX version :)
>
> On 4/10/07, Tobias Ivarsson <thobes at gmail.com> wrote:
> > >
> > > Well, I was right. My last message was still interesting. I
> substituted
> > > all org.neo4j.api with org.neo4j.api.core and added the getId() method
> > to
> > > Relationship. However the problem with the next() method is still
> there.
> > > ...
> > > I did a tiny experiment with a simple Iterator class and reflection,
> and
> > > it turns out that the double methods are a result of the generics
> > system.
> > > If I declare a next() method to return Object, I only get one version
> of
> > > it. If I declare it to return something else I get two versions, one
> > that
> > > returns what I have declared, and one (volatile) that returns Object.
> > >
> > > On 4/10/07, Tobias Ivarsson <thobes at gmail.com> wrote:
> > > >
> > > > I dug a bit deeper into this using reflection, and found a method
> > called
> > > > nextNode that I worked instead. But then I ran into the same problem
> > with
> > > > the currentPosition metod as well. So It couldn't have been a
> wrapper
> > > > problem. Armed with the java reflection api in an interactive python
> > shell
> > > > (a rather powerful weapon I must say) I dug even further into this
> > matter
> > > > and found that AbstractTraverser has two methods (reported by
> > > > getDeclaredMethods() ) named "next" and two methods named
> > "currentPosition",
> > > > with different signatures. They all take no parameters, which is why
> > JPype
> > > > cannot know which method to invoke when I try to call next().
> However
> > the
> > > > return types vary:
> > > > The first next() returns org.neo4j.api.Node and the second
> > > > java.lang.Object
> > > > The first currentPosition() returns
> > > > org.neo4j.traversal.TraversalPosition and the second
> > > > org.neo4j.api.TraversalPosition
> > > >
> > > > Are they there in the code or is this some strange artifact caused
> by
> > > > the Generics system?
> > > > If they are there in the actual code, I assume that this will be
> > cleaned
> > > > up by the time the migration to the new api is completed. Perhaps
> even
> > with
> > > > the next beta release?
> > > >
> >
>
> The thing about overloaded return type sounded very strange so I did a
> check
> with the reflection API and got the same results as you did. The two
> next()
> methods are as you say because of generics. Interesting quiz:
>
> http://www.weiqigao.com/blog/2007/01/18/thursday_java_generics_quiz.html
>
> I would probably have reasoned the same way Eric Burke did in the first
> comment but the Bar class will have two "bar" methods with overloaded
> return
> types when compiled...
>
> About the currentPosition() method I am not sure why we get two methods
> there since no generics is involved (in that method signature). Maybe it
> was
> possible to have this in 1.4 too then? I renamed the
> org.neo4j.impl.traversal.TraversalPosition to org,
> neo4j.impl.traversal.TraversalPositionImpl and changed the
> org.neo4j.impl.traversal.Traverser.currentPosition() to return
> org.neo4j.api.core.TraversalPosition (instead of
> .impl.traversal.TraversalPosition) and after compile I now only have one
> currentPosition() method. I'll make sure this gets in the next release.


Well, there is no generics involved. However there is type erasure involved.
The interface specified that it should return
org.neo4j.api.core.TraversalPosition and the method itself returned
org.neo4j.impl.traversal.TraversalPosition. This was not allowed in 1.4 (I
think... at least it wasn't in 1.3) so therefore type erasure is involved to
coerce the class to its interface, and this is done by adding the extra
method.


--
> Johan
> _______________________________________________
> Neo mailing list
> User at lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>


More information about the User mailing list