Jim,

> Please excuse my general ignorance of things Jaybird. I do have a
> passing familiarity with Java and database related stuff, but I'm
> new to Jaybird and things are working the way I, perhaps naively,
> think they should.

This is a bug. I will explain the situation in details, so it is clear
for others.

In general situation is the following: embedded version of Firebird is
supported by JayBird. JNI bridge was created by Ryan Baldwin, but if I
remember correctly he had problems with Solaris. Unfortunatelly I do
not have access to Solaris box and cannot test driver there. This is
also the reason why no binary version of JNI bridge is available for
SPARC. Also, embedded server is supported only in v 1.5 which is not
yet released (though it is in RC phase).

> The problem is related to endian-ness. It a nutshell, Jaybird
> doesn't work.

Very possible.

> After the call to isc_dsql_fetch, JXSqlda::JXSqlda (JXSqlda
> constructor) sucks data out of the XSQLDA, allocating characters
> arrays corresponding to the data length plus a fudge. Sometime
> later, these character arrays get copied into fresh new Java byte
> arrays and stashed in the Java class XSQLVARImpl.. An actual
> ResultSet.getInt ends up with a call to
>
> public int decodeInt(byte[] byte_int){
> int b1 = byte_int[0]&0xFF;
> int b2 = byte_int[1]&0xFF;
> int b3 = byte_int[2]&0xFF;
> int b4 = byte_int[3]&0xFF;
> return ((b1 << 0) + (b2 << 8) +
> (b3 << 16) + (b4 << 24));
> }
>
> While this might work on Intel or a VAX (god help us), it is the
> wrong byte order for, say, a Solaris box. And by sheer bad luck,
> that happens to be the platform of choice of a client.

Original JayBird expects to receive bytes in the order sent over the
wire. As far as I know this order is fixed and is a big endian order.
However, on Intel JNI bridge receives data already in little endian
order. That is the reason for XSQLVARImpl class. However, on the
platforms with big endian we should use original XSQLVAR implementation.

> Perhaps the embedded driver is not an official part of Jaybird -- it
> certainly isn't on the binary kit.

Not for Solaris. But this bug seems to be easy to fix.

> Or maybe it was intended for development usage on Intel-only
> platforms (gratefully extended by AMD, of course).

No. It should be usable everywhere where Firebird and Java is available.

> And possibly my analysis of the code is all wet.

Your code analysis is as usual sharp and precise.

> But for the time being, having integers come out with the byte order
> inverted is inconvenient.

"Inconvenient" is probably the wrong word. :) It's a bug.

> What, pray tell, is the official status of the embedded driver and
> to whom should a humble supplicant address his prayers for relief?

Official status of the embedded driver - it is going to be part of the
1.5 release. However I cannot tell anything about Solaris on SPARC (I
suspect that Solaris on x86 would work ok) because:

a) there is no official embedded Firebird for Solaris;
b) I do not have access to Solaris box to compile and test driver there.

Jim, if you can somehow provide me access to your Solaris box with
embedded Firebird there I will try to fix the issue. It seems to be
easy to fix:

a) add a constructor (int, int, int, byte[], String, String, String)
to the XSQLVAR class;

b) add #ifdef to xsqlda_wrapper.cpp:66 to instantiate
"org/firebirdsql/gds/XSQLVAR" on Solaris instead of the XSQLVARImpl.

Or if you have time and desire to fix it yourself, I will be happy to
commit your changes to the CVS.

Thanks!
Roman