[jboss-jira] [JBoss JIRA] (JGRP-1771) Replace Exposed{Input, Output}Stream with ByteArray{Input, Output}Stream

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12943094#comment-12943094 ] 

Bela Ban edited comment on JGRP-1771 at 2/10/14 10:57 AM:
----------------------------------------------------------

All relevant methods to read from and write to byte buffers will be defined in org.jgroups.util.Bits, similar to java.nio.Bits. This is only needed for *byte arrays* as *ByteBuffers* already contains methods to do that.

h5. Re endian-ness
Java uses the big-endian format all the time, and since JGroups does not have to communicate with non-Java processes, we'll ignore endian-ness for the time being. (Note that ByteBuffer does *not* ignore endian-ness).

Shift operators ({{<<}} {{>>}}) defined by Java and used in Bits don't simply shift left or right, but they shift towards the MSB ({{<<}}) and LSB ({{>>}}) respectively, so the result is the same in little or big endian systems, and that's why communication between processes on different architectures works in Java.

h5. Example
The integer 322649 is stored as {{0 4 \-20 89}} on big endian systems and {{89 \-20 4 0}} on little endian systems. However, {{(byte)(322649 >> 8)}} always returns {{\-20}} ({{236}}), regardless of whether it is run on a little- or big endian system.
                
      was (Author: belaban):
    All relevant methods to read from and write to byte buffers will be defined in org.jgroups.util.Bits, similar to java.nio.Bits. This is only needed for *byte arrays* as *ByteBuffers* already contains methods to do that.

h5. Re endian-ness
Java uses the big-endian format all the time, and since JGroups does not have to communicate with non-Java processes, we'll ignore endian-ness for the time being. (Note that ByteBuffer does *not* ignore endian-ness).

Shift operators ({{<<}} {{>>}}) defined by Java and used in Bits don't simply shift left or right, but they shift towards the MSB ({{<<}}) and LSB ({{>>}}) respectively, so the result is the same in little or big endian systems, and that's why communication between processes on different architectures works in Java.

h5. Example
The integer 322649 is stored as {{0 4 -20 89}} on big endian systems and {{89 -20 4 0}} on little endian systems. However, {{(byte)(322649 >> 8)}} always returns {{-20}} ({{236}}), regardless of whether it is run on a little- or big endian system.
                  
> Replace Exposed{Input,Output}Stream with ByteArray{Input,Output}Stream
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1771
>                 URL: https://issues.jboss.org/browse/JGRP-1771
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Currently, when reading a message, we create an ExposedByteArrayInputStream and a DataInputStream on top of it. Then we read the message or message list off of the DataInputStream.
> The problem is that DataInputStream creates an 80 byte buffer for every creation, and also an array of 80 chars (additional 160 bytes + array header + pointer).
> Same thing for sending a message or message list.
> SOLUTION:
> * Create a ByteArrayInputStream which implements DataInput and works by reading from the passed in byte array
> ** Eventually, when switching to NIO.2, use a ByteBufferInputStream which works off of NIO ByteBuffers instead of byte arrays
> *** Possibly replace readFrom(DataInput) with readFrom(Buffer) where Buffer implements reading from an NIO ByteBuffer (and possibly also from a simple byte array). Ditto for sending.
> * Similar solution for sending of messages / message lists
> * Also create the corresponding unit tests

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira