Object based annotations allow creating ClassLoaders - it is not only a
way to download code but to:
1. Make sure only trusted code is executed
2. Resolve any dependencies and create the whole ClassLoader structure
when deserializing objects
So URL handler is not enough - alternative implementation of
RMIClassProviderSpi is necessary.
But anyway - if there is a need to encode annotations as Strings - I do
not see anything wrong with that except that I personally do not see it
necessary.
Thanks,
Michal
Peter wrote:
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.