On Thu, 2006-01-19 at 23:52, Bill Shannon wrote:
> Sheetal Vartak wrote:
> > Hi All,
> >
> > Recently we uncovered that a mismatch in the JDK versions used on the
> > client and server side (9.0) causes some clients to fail.
> > This issue is seen only when the use of the java.math.BigDecimal API is
> > involved. In the Quick Look tests, the EJB converter test uses this API.
> >
> > The following matrix gives more information about which update releases
> > of 1.5.0 work well together when used on the client and server side.
> >
> > Server ------>
> > JDK 1.5.0|update 4 | update 5 | update 6
> > ------------------------------------------
> > client update 4 | yes | no | no
> > | | | |
> > | ------------------------------------------
> > | update 5 | no | yes | yes
> > v | | |
> > ------------------------------------------
> > update 6 | no | yes | yes
> > | | |
> > ------------------------------------------
> >
> > Update 4 of 1.5.0 does not work with the future updates. But updates 5
> > and 6 work with each other.
> >
> > We will be looking into fixing this issue in the ORB code.
> > All update releases after update 4 (JDK1.5.0) work well with 9.0.
>
> Is this a bug in the ORB code shipped with the app server?
Yes.
>
> Is it *not* a bug in the ORB in the JDK?
No: the same bug exists in the ORB in both the JDK and the
app server (the serialization code is virtually identical in both).
>
> What is it that changed in the JDK that caused this problem?
>
Someone on the JDK team changed the internal representation
of BigDecimal (presumably) to improve performance. The need
to preserve the serialized representation then required the
addition of a writeObject method to convert the format
(if necessary) before serializing the object. Apparently
the ORB code does not handle this case of class evolution
properly: that's where more investigation is required.
Bottom line: 5.0u5 added the write object method, which
causes the 5.0u4 (and probably anything earlier) interop
failure with 5.0u5 and later.
Ken.