1.3.1: Fix CDRInputStream.java optimization code to avoid chunk overflow errors

One of my licensee submitted these two web bug reports for 1.3.1.x release of JRE on Linux platform:

#1. Synopsis: RMI-IIOP MARSHAL: Chunk-overflow
Description: EAS have We have a problem with a RMI-IIOP communication.

The same test case has been tested in 3 different situations :

Our ORB to Our ORB - works
JDK ORB to Our ORB - doesnt work
JDK ORB to JDK ORB - doesnt work

After doing a LOT of analysis on the IIOP traces in the 3 different
cases, I was able to understand the extremely complex IIOP flow,
and finally to understand at what point in the flow, the JDK
ORB was becoming unhappy.

The RMI-IIOP trace is FULL of IDL value types. Each value type is
streamed as a Value tag, followed by an optional codebase, followed
by a repository id, followed by the data. Certain types of value types
(due to their inheritance hierarchy, or nesting), have to be chunked
- that is, their data is sent in "blocks" which are demarcated.
The rules about Chunking in IIOP are very complicated. What was
happening was that one value type was finishing and another starting.
The chunk that the first one was sent in was ending, but JDK ORB
didnt detect this, and thought that the chunk had been overflowed.

The reason the JDK ORB didnt detect this, is because the code for
closing chunks is contained in a method for checking alignment
(to 2, 4 or 8 byte boundaries) when reading new data. However,
JDK ORB had added an optimisation in read_long() which avoided calling
this alignment checking if it was sure that one is already on a 4
byte boundary. What they forgot with this "optimisation" was that
the alignment method does more than just check alignment - it handles
starts and ends of chunking.

By removing the one line if clause (to avoid the optimisation),
the code works.

I also noted that this optimisation has been removed from JDK 1.4
We cannot go direct to JDJK 1.4, so we need a bug release for JDK
on Linux for 1.3.1....

--------------------------------------------------------

#2. Synopsis: RMI-IIOP org.omg.CORBA.MARSHAL: Chunk overflow at offset 3827 minor code: 998

Description: It is not easy for me to tell you how to reproduce the problem,
but I can describe to you what is happening, and how to correct it.

What we have seen is that when using RMI-IIOP, we get the given
exception

org.omg.CORBA.MARSHAL: Chunk overflow at offset 3827 minor code: 998

After EXTENSIVE analysis, we have come to the following conclusion :
----

The RMI-IIOP stream in a reply message contains several complex
"RMI-IIOP value types", several of which need to be chunked.

We have tested the test case with a (rather complicated) application
with

1) JDK client to 3rd party server
2) JDK client to JDK server
3) 3rd party client to 3rd party server

Cases 1 and 2 dont work (and get the given exception) and case 3
works.

We have analysed the RMI-IIOP stream received at the JDK client
and believe it to be correct.

What we have seen after looking at the given stream, and the
given location of the chunk overflow, is that a chunked valuetype
finishes on a 4 byte boundary, and is followed directly by
another value type. The exception is thrown when attempting to
read the repository id of a new value type, and does not seem
to have registered that the previous chunk is finished. The code
for "finishing" chunks is in CDRInputStream.alignAndCheck().
alignAndCheck() ends a chunk if the current stream position is
equal to the expected end of a chunk.
However, when the valueType tag for the "following" valueType is
read, alignAndCheck is not called (which would have lead to the
chunk being finished), because there is an optimisation in
read_long() which avoids calling alignAndCheck() if a quick
check of the alignment shows that one is already on a 4 byte
boundary. This optimisation seems to "forget" that alignAndCheck
doesnt JUST do alignment, it also does chunk control.

When I removed the line :

if ((index & 3) != 0 || index + 4 >= size)
alignAndCheck(4, 4);

and replaced with simply

alignAndCheck(4, 4);

the test case worked perfectly. I have studied the code in JDK 1.4
and this "optimisation" is NOT present there.

We cannot go to JDK 1.4 directly in our product, and so would
like this correction in a JDK 1.3.1 bug release for Linux.