> I still think that when Java is expecting a float, though, that it's a
> mistake for Inline::Java to get the stringified form and run it through
> unpack(U*). It would be better to get the numified form, no matter
> what the *original* form is, and encode that in a way that the server
> on the other side can translate easily to a Java float. That would
> line up better with what perl subroutines/statements do when they
> expect to work with a number.
I think you're right. This is the real point. I've finally tracked down
exactly what is going on, and it's not pretty. Basically, unpack always
converts its argument to a string via SvPV, which on linux ends up calling
gcvt() with a precision of 15. This throws away bits. One could consider
this a bug in perl, although the naive way to fix it would result in very
ugly default stringification of most floating point numbers. I think the
bottom line is that unpack is not the correct way for Inline::Java to send
floats to java. Perhaps what is needed here is an implementation of
unpack("U*") that works properly for floats, preferably in XS.
Ben
