RE: JSR 160 is FINAL !

Hi Brian,

> > That's strange.
> > The serialization stuff works fine with all JSR 3
> > classes, it is only a matter of having the
> > Comparator implemented correctly, unless I am
> > totally off road here.
> 
> What I am seeing is different SerialVersionUIDs (which
> will cause the default implementation of the
> ObjectInputStream to choke).  

Ah.
I have paid attention to the names of the serialized fields in the JSR 160 classes, but it's possible that:
1) I forgot to stick with the official name
2) The name was changed between EA2 and Final
3) The modifiers are not right (I tend to add final to those fields that allow to be final).

> This suggests to me that we have some differences
> between our classes (9/26 tested) and the RI classes. 
> The plan is to walk through these class by class - but
> are there any implications for me looking at the RI
> source code and working on the MX4J source code?  

Should be simpler: javadocs have both serialVersionUID and field names/modifiers. Should be enough to stick with the specification.

If there are major incompatibilities (different field names or type), please discuss: as I told I paid attention not to introduce major differences, and if there are would sound strange to me.

I would do like this:

1. Pick a class, eg JMXServiceURL
2. Compare MX4J implementation with official (Final) javadocs: if the serializable fields match, write the test that confirms serialization interoperability works. If serializable fields don't match, modify MX4J to match, or eventually think if it's the case to implement writeObject() and readObject().
3. If the test fails, but fields match, try to add serialVersionUID. I see now that all JSR 3 MX4J class have serialVersionUID, even if the implementation is trivial (take eg JMException).

I think field matching and serialVersionUID will do the job in most cases.

> I haven't read Sun's source license for this one yet,
> but I can't imagine that it's extremely open on this
> point.  Opinions or experiences?

I would look at the RI source as last resource. 
Javadocs should be enough; if not, DON'T decompile the classes, I repeat, DON'T decompile.

Would it help you if I complete some case/test so that you can take as example ?

Thanks,

Simon

> > Before writing something new, take a look at how the
> > tests for JSR 3 work.
> > They should be very very similar for JSR 160. Given
> > that, it should be sufficient to implement the
> > RemoteInstantiator and the RemoteComparator. The
> > rest should do the job.
> > In fact, the serialization tests for the JSR 160
> > part inherit from the one of the JSR 3 part.
> 
> I looked into the serialization tests for the JSR 3
> (non remote) classes - and they do look very similiar.
>  There may have been an exercise to compare and
> address the possibility of non-private fields or
> methods added to (or not reflected in) the MX4J
> implementation of JSR3.
> 
> Brian
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
> 


-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/