* Re: JGNAT, Byte arrays, and Stream_Element_Arrays [not found] <3A806533.8EFCFB0@earthlink.net> @ 2001-02-07 19:46 ` Stephen Leake [not found] ` <3A829458.19037392@earthlink.net> 0 siblings, 1 reply; 5+ messages in thread From: Stephen Leake @ 2001-02-07 19:46 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <3A829458.19037392@earthlink.net>]
* Re: JGNAT, Byte arrays, and Stream_Element_Arrays [not found] ` <3A829458.19037392@earthlink.net> @ 2001-02-08 18:28 ` Stephen Leake 2001-02-08 22:00 ` Marc A. Criley 0 siblings, 1 reply; 5+ messages in thread From: Stephen Leake @ 2001-02-08 18:28 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: JGNAT, Byte arrays, and Stream_Element_Arrays 2001-02-08 18:28 ` Stephen Leake @ 2001-02-08 22:00 ` Marc A. Criley 2001-02-09 14:19 ` Stephen Leake 0 siblings, 1 reply; 5+ messages in thread From: Marc A. Criley @ 2001-02-08 22:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: JGNAT, Byte arrays, and Stream_Element_Arrays 2001-02-08 22:00 ` Marc A. Criley @ 2001-02-09 14:19 ` Stephen Leake 2001-02-09 16:50 ` Marc A. Criley 0 siblings, 1 reply; 5+ messages in thread From: Stephen Leake @ 2001-02-09 14:19 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: JGNAT, Byte arrays, and Stream_Element_Arrays 2001-02-09 14:19 ` Stephen Leake @ 2001-02-09 16:50 ` Marc A. Criley 0 siblings, 0 replies; 5+ messages in thread From: Marc A. Criley @ 2001-02-09 16:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-02-09 16:50 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3A806533.8EFCFB0@earthlink.net> 2001-02-07 19:46 ` JGNAT, Byte arrays, and Stream_Element_Arrays Stephen Leake [not found] ` <3A829458.19037392@earthlink.net> 2001-02-08 18:28 ` Stephen Leake 2001-02-08 22:00 ` Marc A. Criley 2001-02-09 14:19 ` Stephen Leake 2001-02-09 16:50 ` Marc A. Criley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox