Re: JGNAT, Byte arrays, and Stream_Element_Arrays

Re: JGNAT, Byte arrays, and Stream_Element_Arrays

[Stephen Leake]

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

> What is the best way to convert between Java byte arrays, 

You've tried the "correct Ada way", and the compiler rejected it. So
you're stuck. 

You could send some money to ACT and ask them.

On the other hand, if you tell us why you want to do this, maybe there
is a better way.

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.

Is Stream_Element actually 8 bits?

> as bound to in the Ada form (from Java.ads):
> 
>   type byte_Arr_Obj is array (Natural range <>) of byte;
>   type byte_Arr     is access all byte_Arr_Obj;
> 
> and a corresponding Ada.Stream.Stream_Element_Array?
> 
> In similar situations, one might define an access type to
> Stream_Element_Array, and then Unchecked_Convert between that type and
> byte_Arr.
> 
> However, JGNAT rejects such an instantiation of Unchecked_Conversion,
> stating:
> 
>    incompatible "jvm" types for unchecked conversion
> 
> Though I don't know the specifics of what's all involved, the idea that
> that conversion would not be valid doesn't surprise me.
> 
> So, how does one convert between objects of those types (in bulk)?  I'd
> hate to think I'd have to traverse the array and unchecked_convert each
> individual byte to a Stream_Element.
> 
> Thanks for any suggestions,
> 
> Marc A. Criley
> Senior Staff Engineer
> Quadrus Corporation
> www.quadruscorp.com

-- 
-- Stephe

Re: JGNAT, Byte arrays, and Stream_Element_Arrays

[Stephen Leake]

"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

Re: JGNAT, Byte arrays, and Stream_Element_Arrays

[Marc A. Criley]

Stephen Leake wrote:
> 
> "Marc A. Criley" <mcquadex@earthlink.net> writes:
> 
> > 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?

Yes, I'm using Java's socket class for the socket communications.  (Keep
in mind that while I'm writing Ada, it's _all_ being compiled into Java
Byte Code.)  Socket packages written in Ada (such as Tardieu's
AdaSockets, which is used on the server) at some point import and invoke
OS functions, so those are not usable unless I wanted to go the JNI
route--which I don't.

> > 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?

Yes, I am sending structured data as a stream of bytes, and yes, one
side of the interface (the JVM client) is converting the data to network
byte order.  For now, both client and server are running on the same
PC-Linux box.

> > 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.

No, even after the conversion problem was taken care of, JGNAT still
sometimes has problems correctly processing stream attributes.  I was
monitoring the data at the byte level as it came in, and there was
nothing wrong with it.  The JGNAT generated code simply froze up in some
instances.  (Same location each time, so it wasn't random with each
run.)

> 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.

I am very much aware that I'm playing close to implementation and
platform dependencies :-)  And that the solutions I come up with may not
be portable across platforms.  But I had to start banging my head
against the wall somewhere :-)

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

The idea of trying to get the DSA to work with a natively compiled
server and a JVM client scares me even more than using the Java sockets
class!

> --
> -- Stephe

And by the way, got the whole thing happily working.  Had to step out
and do the "Engineer's Dance"!

Marc

Re: JGNAT, Byte arrays, and Stream_Element_Arrays

[Stephen Leake]

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

> <snip>
> I am very much aware that I'm playing close to implementation and
> platform dependencies :-)  And that the solutions I come up with may not
> be portable across platforms.  But I had to start banging my head
> against the wall somewhere :-)
> 
> > You need to use the Distributed Annex facilities to make this work
> > properly (never used them myself, so I can't help more).
> 
> The idea of trying to get the DSA to work with a natively compiled
> server and a JVM client scares me even more than using the Java sockets
> class!

I gather you are not familiar with the DSA, but are familiar with
sockets. However, the DSA was _designed_ to solve exactly the problem
you are experiencing, in a _portable_ way. Sockets are a low-level
tool in the solution. 

Think of it this way; the DSA is to sockets as Ada rendezvous and
protected types are to mutex and semaphores.

Take the time to learn the DSA; it will be worth it! (Well, assuming
the DSA is implemented by JGNAT; if not, maybe you could now implement
it, and do us all a great service).

> And by the way, got the whole thing happily working.  Had to step out
> and do the "Engineer's Dance"!

Congratulations !

-- 
-- Stephe

Re: JGNAT, Byte arrays, and Stream_Element_Arrays

[Marc A. Criley]

Stephen Leake wrote:
> 
> "Marc A. Criley" <mcquadex@earthlink.net> writes:
> 
> > The idea of trying to get the DSA to work with a natively compiled
> > server and a JVM client scares me even more than using the Java sockets
> > class!
> 
> I gather you are not familiar with the DSA, but are familiar with
> sockets. However, the DSA was _designed_ to solve exactly the problem
> you are experiencing, in a _portable_ way. Sockets are a low-level
> tool in the solution.
> 
> Think of it this way; the DSA is to sockets as Ada rendezvous and
> protected types are to mutex and semaphores.
> 
> Take the time to learn the DSA; it will be worth it! (Well, assuming
> the DSA is implemented by JGNAT; if not, maybe you could now implement
> it, and do us all a great service).
> 

Actually I am comfortable with the DSA, though I've not used it on a
production contract, I've messed around with it a lot at home. 
Before..uh..certain factors came into play at my former employer, I had
started to lay out the design for a migration from an explicit
socket-based IPC to the DSA facilities.  I changed employers before
anything could come of it, though.

Using JGNAT to generate the client isn't being done entirely for the
novelty value :-), there is a _code_ portability factor, as well as the
potential for running the client as an (gn)applet.  For easing data
portability I may get into an XML approach (and the
design/implementation is flexible enough to "plug in" an XML "conversion
module"), but I'm focusing on raw functionality at the moment.

Marc A. Criley