I have actually given up on the idea of object annotations encoded as
Strings (in whatever form).
Simply speaking it does not make any sense really:
- it would complicate the solution because of additional encoding and
decoding logic
- it would influence performance because of additional encoding and decoding
- it would complicate maintaining codebase objects identity (since
encoded annotation would be a separate stream)
- it would be incompatible with existing clients (if there are any :) )
anyway - all expect the annotation to be a space separated list of URLs
I have starting working on a compatibility layer that would allow
existing clients to download the class loading infrastructure from a
codebase URL magically (using existing RMI infrastructure).
TBH - I do not see any benefit in maintaining backwards compatibility -
Jini/River is out of favor nowadays and existing software needs upgrade
anyway because of security and concurrency fixes.
Thanks,
Michal
Peter Firmstone wrote:
Mike, I recall the last time I looked at object based annotations, there was a
backward compatibility issue because both ends of the Marshal streams expect
string based annotations as does RMIClassLoader.
However if you are still keen to investigate object based annotations there's
no reason you couldn't treat a string like a char array = byte array (beware
signed byte) and have a RMIClassLoaderSPI deserialize the objects after they
were sent in string form?
Regards,
Peter.
Sent from my Samsung device.
