Re: JGNAT, Byte arrays, and Stream_Element_Arrays

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

"Marc A. Criley" <mcquadex@earthlink.net> writes:

> I'm trying to implement an instance of the "Ada can be anywhere"
> philosophy--compiled natively on the server (GNAT 3.13p) and to Java on
> the client (JGNAT 1.1p).  (I've just started messing around with JGNAT,
> so right now I'm in the "experimental flailing" stage :-)

Ok.

> Based on some past work I did with tying Streams and their
> associated attributes together with sockets, I've attempted to adapt
> that code to work with Java's sockets, hence the work with
> byte_Arr(ays). I've had partial success, at least with the specific
> data streams with which I'm working.

Now I'm confused. Why use "Java's sockets" if you are attempting an
"all Ada" approach. I guess you mean "use a Java 2 socket class",
because there is no equivalent Ada package?

> I did discover that I had to reverse the order of the bytes, at
> least on a PC linux platform--so as it turned out that pretty much
> ruled out the possibility of bulk conversion anyway. 

Hmm. This implies you are attempting to send structured data as stream
of bytes, and some of the data is multibyte (eg 16 bit integers), and
one side of the stream interface is converting to network byte order
but the other side isn't. Now I'm really confused! Or are the client
and server different machines with different native byte order?

> Plus, JGNAT's implementation of some of the Stream attributes, like
> 'Input, seems a little shaky. Sometimes doing a String'Input of data
> freezes up, even though the data was of course sent via
> String'Output.

Certainly if one side is doing conversions to network byte order and
the other isn't, you will have problems. The string length will be
wrong, for one.

> > Are you importing a serialized object? Then maybe you can
> > re-import the relevant functions, but declare them to use
> > Stream_Element_Array rather than Java.byte_Arr_obj. this might not
> > work, if the pointers really are different.
> 
> The native, server side is the one in control of the data objects, so
> there's no explicit interaction between _Java_ language software
> (objects) and Ada software.  It's all Ada, with the client software
> being compiled to JBC (I know the client is interacting with "Java"
> software, but that software is being treated more as a library
> resource.)

Ah. So you have native (what machine?) Ada code generating a stream
from structured data, but then you are reading that stream with a Java
stream library. Sounds like a recipe for trouble. What does JGNAT do
for Ada.Streams? Maybe that's what you are using. I seem to recall
that the JVM spec defines byte order in streams.

Ada makes no guarrantee that a stream written by one compiler/machine
will be readable by a different compiler/machine. Here you have
GNAT/PC (I guess) writing, and JGNAT/JVM reading, so it is allowed to
not work.

You need to use the Distributed Annex facilities to make this work
properly (never used them myself, so I can't help more).

> > Is Stream_Element actually 8 bits?
> 
> Yes:  type Stream_Element is mod 2 ** Standard'Storage_Unit;
> 
> That's GNAT's implementation on Linux, the LRM does not specify a size.

Exactly, that's why I asked. I'm guessing that Standard'Storage_Unit
is 8, on both the native and JVM machines. Actually, I'd be surprised
if it isn't (but there are machines where it isn't).

-- 
-- Stephe