Hi guys, Attached is a test version of Inline::Java 0.52_99 that tries to address the above-mentionned issues. Basically, if the class of an object returned by a method is not public and is not in the unnamed package, Inline::Java will assing the return type of the method as the object type instead of the "real" object type.
I did a few tests and this seems to fix some of the specific JBDC-type errors without breaking anything in the test suite. The only file modified (with respect to these issues) is InlineJavaProtocol.java, see the new AutoCast method. If anyone has a chance to try it out on real world problems that would be great. Note: There are also some minor bug fixes in there that were in my sandbox, it's minor stuff that shouldn't affect general functionnality. Thanks a lot, Patrick On Fri, Oct 2, 2009 at 10:58 AM, Jason Stelzer <men...@neverlight.com>wrote: > On Fri, Oct 2, 2009 at 10:11 AM, Patrick LeBoutillier > <patrick.leboutill...@gmail.com> wrote: > > Choosing to always give objects the return types of the methods that > > returned them would break a lot of things, > > and would actually introduce more casting (i.e. anytime you would work > with > > generic containers, like Vectors, you > > would always need to cast (just like in Java basically)). That in my > opinion > > would remove some of the "magic"... > > Yeah, I can see that side of the issue too. Most of the stuff I've had > to work around has been stuff surrounding interfaces for similar but > slightly different reasons. For instance, when dealing with EJB, you > have the same kind of problems. You look up a resource in jndi, you > get back a portable remote object (the primorial object type for ejb) > and have to narrow the cast based on an interface. When you get right > down to it, its corba roots show pretty clearly. So, I did what seemed > best. I encapsulated all that casting in a perl object facade for the > ejb and presented a more perlish interface to calling code. Keep java > looking like java, perl looking like perl and glue code as out of the > way as possible :) > > The JDBC thing is kind of a different issue. For JDBC, there's a very > clear distinction. JDBC is all about interface, not implementation. > Initially I was thinking that it would be as simple as adding a little > extra meta info about classes. Using reflection, you can pretty easily > see what the return types of any given methods are. The issue, as you > correctly point out, is that when you're dealing with concrete > implementation classes, you can't really derive if a person is calling > them from the context of an interface, or in the context of a plain > old object reference. In some cases it would just result in a bunch of > wasteful casts. > > > > And because all overridden Java methods are virtual, meaning you can't > > really call the wrong method when it's overridden > > (unlike C++ I think), in reality this only seems to be a problem in these > > specific circumstances: non-public classes that implement public > interfaces > > or extend public base classes. > > > > Agreed. And there are other ways to work around the issue outside of > Inline::Java. What we're running into issues with are a vendors > implementation of the interfaces. > > I'm happy to give it a shot. Send me a patch, git url, svn url, or a > tarball. I can test it out with mysql, oracle and probably a couple > other databases if I force myself to make the time. > > I'm glad for the discussion, I'll see if I can come up with some > patches for JDBC.pm that'll let it be a little more strong handed > about forcing the interface casts. > > -- > J. > -- ===================== Patrick LeBoutillier Rosemère, Québec, Canada
