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

[Per Bothner <per at bothner dot com>]

Hoehle, Joerg-Cyril wrote:
> Actually, I'd appreciate some documentation clarification about 
compilation
 > vs. interpretation.

There are three separate issues:

(1) Compilation vs interpretation.  Kawa (and BRL) compiles almost
everything.  Only very simple expressions are interpreted.  As soon
as an expression contains a let or a lambda, for example, it is
compiled to bytecode, even when using eval.

(2) Immediate compilation vs compiling to a .class.  After Kawa compiles
an expression into one or more bytecode classes, it has two choices:
Immediately create classes, using the ClassLoader defineClass method,
in which case no files are actually created.  ALternatively, Kawa can
write out a .class file or a .zip file, for future use.

(3) Procedure calls that get inlined or simplified at compile time
vs one that get applied at run time.  For example the invoke method
will (assuming we're not interpreting) get expanded to primite bytecode
'invokevirtual' instructions, though going through the Scheme
procedure call mehcnism, or looking up the method at run-time.  This
assumes the compiler can figure what is the correct Java method to
generate code to invoke.

BRL in principle has the same issues.  However, the current BRL does
some tricks with eval and macro re-writing, which means it doesn't
get the full benefit of Kawa's compiler.  That is because BRL pre-dates
the improved support in Kawa for multiple programming languages.
Current Kawa releases include a "BRL-lite" which is a re-implementation
of the BRL core using the current multi-language framework.  BRL-lite
is a functional BRL implementation, but missing much of the useful
BRL library.  Bruce has mentioned that a future BRL release will be
based on this.

> BRL users would also benefit from this. For example, it's completely
 > unclear to me whether code from a .brl file ever gets compiled to JVM
 > bytecodes me whether code from a .brl file ever gets compiled to JVM
 > bytecodes or whether a Lisp (Scheme) interpreter handles all
s-expressions.

I believe (Bruce, correct me if I'm wrong) that BRL expressions are
either interpreted (if trivial) or compiled in immediate mode
(otherwise).  However, BRL does not compile an entire .brl file as a
unit to bytecode - it evaluates a piece at a time.  This is what is
fixed with the "BRL-lite".

> The only obvious thing is that using BRL doesn't generate .class files
> in the file system. That doesn't mean it does not generate classes or
> bytecode inside the JVM - does it?

It does generate classes inside the JVM.  BRL-Lite allows you to
pre-compile .brl files to .class files, either servlets or stand-alone.

> I believe you meant java.math.BigInteger for unbounded integers?

No, I meant gnu.math.IntNum.  I don't use java.math.BigInteger.

> It seemed to me you use gnu.math.* so as to work with older JVM which
> don't have java.math.*, while newer Java code (esp. JDBC) use
> java.math.BigInteger.

java.math.* doesn't support mixed-mode arithmetic.  Also, I suspect my
implementation is faster.  Kawa doesn't currently support arithmetic on
java.math.BigInteger at all, or know anything about it.  For better
compatiblity with JDBC that could be changed, though that requires
re-implementing all the Kawa arithmetic.  It would also be needed if I
implement JDOQL using Kawa, which seems like a neat idea.

> Or is it because java.math doesn't supply all numeric functions 
(exponentiation,
 > boole & bit-and, trigonometry on large numbers??)?

Exactly.  And it doesn't support infinite-precision fractions.

> This looks as suspicious:
> #|kawa:72|# (let ((one :: <int> 1)) (invoke one 'get-class))
> class gnu.math.IntNum -- as if the type declaration was ignored.

You're going to get strange results anyway - after all an <int>
isn't a class, so you can't invoke getClass on it.  Therefore,
Kawa has to convert teh <init> back to an object.

> #|kawa:77|# (let ((one :: <int> 1)) (invoke rs 'getObject one))
> Argument  to 'sun.jdbc.odbc.JdbcOdbcResultSet.getObject' has wrong type
> 	at gnu.expr.GenericProc.applyN(GenericProc.java:74)
> 	at gnu.kawa.reflect.Invoke.applyN(Invoke.java:149)
> 	at gnu.kawa.reflect.Invoke.applyN(Invoke.java:49)
> 	at gnu.mapping.ProcedureN.apply3(ProcedureN.java:46)
> 	at gnu.mapping.Procedure.apply(Procedure.java:117)
> 	at gnu.mapping.CallContext.runUntilDone(CallContext.java:235)
> 	at gnu.expr.ModuleExp.evalModule(ModuleExp.java:189)
> 	at kawa.Shell.run(Shell.java:229)
> 	at kawa.Shell.run(Shell.java:180)
> 	at kawa.Shell.run(Shell.java:167)
> 	at kawa.repl.processArgs(repl.java:275)
> 	at kawa.repl.main(repl.java:528)
>
> Does that mean invoke doesn't get compiled?

It does get compiled, because it's inside a let.  However,
it doesn't get inlined (expanded) by the compiler - it just
gets applied at run-time.

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.
Could you try the latest CVS Kawa to see if the bug is still there?

If you do want to have teh correct method chosen at compile-time
(which I recommend both for execution speed and better error messages),
you need to declare teh types so Kawa cna figure it.  I just realized
(doh) that also need to make sure that the rs has a known
compile-time type.  For example:

  (let* ((con :: <java.sql.Connection>
          (invoke-static <java.sql.DriverManager> 'getConnection
"jdbc:odbc:Abkuerzungen"))
          (st :: <java.sql.Statement> (invoke con 'createStatement))
          (rs :: <java.sql.ResultSet>
             (invoke st 'executeQuery "SELECT * FROM Abkuerzungen"))
          (one :: <int> 1))
         (invoke rs 'getObject one))

Alternative, you can create a 'test.scm' file, and use define:
(define  rs :: <java.sql.ResultSet> ...)
This will work best if you compile the file:
   java kawa.repl --main -C test.scm
   java test
--
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/