Hebrew data from RPG program to Java program incorrectly ordered

Question

I'm sending hebrew data from an RPG program to a Java program and some of the data is coming in not as expected. The RPG program is running on an iSeries machine with CCSID 65535. The java is accessed through remote method invocation.
Most of the hebrew is received by the Java program in logical order. I then process it with Java's Bidi class to get it into visual order as I'm eventually writing it to a PDF. Almost all of the data is OK except for a few lines that are equations.

Assume capital H's are hebrew data. This is how the line should look: 300 X 250 X 500 :HHHH
I'm receiving the line as this: HHHH: 500 250 X 300 X
The 500 is not in the order I would expect and the Bidi class does not handle it properly. There are a few lines such as these and are the only lines that the Bidi class does not work with. I would assume the line to come in as: HHHH: 300 X 250 X 500 as I believe that would be the logical order. It seems to keep the 500 in the RTL segment and then flip to LTR once it hits the X. Does anyone have any ideas as to why this would be?

Thanks for your help.
EDIT: The java is actually invoked through the JNI and not RMI.

Answer 1

So I ended up finding out what was going on here and am answering my own question in case any one else ever runs into a similar issue.

The Hebrew was being stored on the iSeries in code page 424. This is a Hebrew code page so all was well with the storing on the iSeries. We had some print drivers on the iSeries that were handling the Hebrew data correctly so I knew the issue had to be either on the transfer between the iSeries and Java or when we create the String of data in Java.

It turns out that the iSeries was storing the Hebrew in print order so it was already in the order that I needed it to be to write it to the PDF. When we were transferring it to the Java program we were using an RPG character byte array. This character byte array will convert to Unicode when it is sent to the Java method. This Unicode conversion would attempt to process the bidi data that was already in the correct order and was moving data out of order. The fix was to switch to an RPG integer byte array which won't do this conversion. Then when I receive the byte array in Java I get the job's CCSID from an AS400 object and create a new String with it.

The job's CCSID gets returned as a character set. So on our US based system this will return Cp037 and I can use that in a new String(byte[] source, String charsetName) constructor and it will convert the byte array which is in an EBCDIC code page to Java's encoding. On a Hebrew based system this will return Cp424 which I can do the same thing with to convert it.