AW: java.sql.ResultSet.getObject() Kawa(?) bug, (as <int> 1)

[Per Bothner]

Hoehle, Joerg-Cyril wrote:
> Per Bothner wrote:
> 
>>Kawa should be able to figure out that getObject(int) is a closer
>>match than getObject(String).  I'm not sure what it doesn't.

Actually, I think (though I haven't verified) that the reason that
getObject(String) is chosen is that <int> is not a sub-type of
<integer> - there are <integer> values that will not fit in an <int>,
but all <integers> can be converted to <String>, using toString.

To fix this we need a special hack to ensure that converting to
<String> has lower priority.  I'll have to think about how to do that.

> bad: getObject getLong getBigDecimal getDouble getFloat getTimestamp
> bad means: java.sql.SQLException: Column not found
> (i.e. findColumn in backtrace), not the old "Argument  <2spaces>to
> '...getInt' has wrong type", which seems gone now.

So what happens it that it picks the getObject(String) method,
converting the integer argument to a String using toString.

I tried a little test class with overloade getObjects, and then
did:
(let ((r :: <RS> (make <RS>)) (i :: <int> 12)) (invoke r 'getObject i))

That still picked getObject(String), because the compiler doesn't get
to inline the invoke in "immediate" mode.  The logic is in immediate
mode we want fast and simple compilation.  I tending to think that's a
mistake - it is better to have consistency between immediate mode
and compile-to-file mode, given that the compilation overhead is trivial
and partly made up by faster execution.  So I tried the attached patch,
which seems to fix things.  Could you try it?
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Tr.patch
URL: <http://sourceware.org/pipermail/kawa/attachments/20021220/a5cfbe2d/attachment.ksh>