Bitwise operations shouldn't have much performance impact. You could also create a url scheme and handler.
When a ClassLoader retrieves a URL, it doesn't care how it's done, just that it retrieves the class code. eg: obj:[length][bytes] Then install your URL handler in your client jvms. The community agreed to break compatibility with the com.sun namespace change, so it can happen, although admittedly concensus is often difficult, if someone believes a breaking change is necessary, state the reasons, impacts and request a vote.. I've found in the majority of cases with some additional thought and work that the api is extensible, so it may not be necessary to cause breakage. The performance improvent you'll get with your own URL scheme will vastly outstrip standard url schemes by avoiding dns calls, which will exceed the cost of encoding by orders of magnitude. Jini/River 2.x.x has a significant number of unnecessary dns calls. But it sounds like you may have found an alternative option. Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz> Sent: 02/02/2017 06:29:55 am To: dev@river.apache.org Subject: Re: object based annotations 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. > > >
