I tested this against oracle + java6 and it worked with no casting on
the perl side.
#!/usr/bin/perl
use strict;
use JDBC;
JDBC->load_driver("oracle.jdbc.driver.OracleDriver");
my $url = "jdbc:oracle:thin:system/blumfr...@localhost:1521:xe";
print "Getting connection\n";
my $con = JDBC->getConnection($url);
my $ps = $con->prepareStatement(q{SELECT TABLE_NAME FROM USER_TABLES});
my $rs = $ps->executeQuery();
my $foo = 0;
while ($rs->next) {
my $bar = $rs->getString(1);
print "row: foo=$foo, bar=$bar\n";
$foo++;
}
$rs->close;
$ps->close;
$con->close;
On Fri, Oct 2, 2009 at 3:25 PM, Patrick LeBoutillier
<patrick.leboutill...@gmail.com> wrote:
> 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
>
>
