In a word, no because the classes use standard java bytecode and methods.
Standard serializable lambda's are brittle, any change in the
encapsulating class can cause breakage during deserialization.
What I'm looking at doing for lambda's that don't refer to their
enclosing classes object methods, is removing this dependency and
recreating a standard object, with a single static method, one object
method and fields containing captured arguments. Presently an
encapsulating class will be serialized as well, with a lot of
unnecessary code that may pull in other dependencies, so I'm looking at
removing that.
SerializedLambda provides the names of the required methods, so by
intercepting an ObjectOutputStream, before it's serialized and replacing
the SerializedLambda in that stream (provided it implements our marker
interface, that will extend Serializable) we can make lambda's less
susceptible to breakage.
The point where breakage could occur is during serialization at runtime,
if the lambda calls object methods, deserialization will be problem free.
Regards,
Peter.
On 28/05/2014 10:33 PM, Bryan Thompson wrote:
How stable is the lamba translation? If this changes or is different for
different JVMs, will that break things?
Bryan
On Wed, May 28, 2014 at 8:29 AM, Peter<j...@zeus.net.au> wrote:
So far, a subset of Lambda's appear very suitable for marshalling
remotely, where their code can execute in a remote jvm.
A lambda, that doesn't refer to object methods in its enclosing class,
results in the java compiller creating a static method that accepts
captured object arguments, containing the lambda's block code.
With ASM, I can very easily read a class and strip out all but this static
method. A non instantiable class file with no class init.
This class can be given a temporary known name, unrelated to the original
client code (not intended for class loading, but identity).
A named identity of this class can then be created using a message digest
of the class bytes.
The class byte code can be packaged and serialized remotely.
Upon deserialization, the class can be rewritten again (if not loaded
previously) and named after its message digest, and given a new object
method to implement the functional interface, final fields added to hold
serialized captured arguments, and a constructor that accepts the captured
arguments.
It is now a simple basic object that calls a static method with arguments.
The class file would be verified, then loaded into a ClassLoader with no
permissions.
The class would be cached in a Map with weak values, the key being the
message digest, so idential deserialized lambda's wouldn't need to rewrite
and load their class bytecode.
These lambda's could be used in services to allow remote internal
iteration, over large data collections, like distributed hash tables, to
process and return results.
An argument captured by a lambda, could itself be a remote service, used
as a callback. Lambda's could be stored by services, and used like queries
to notify remote listeners of changes in service state.
A bit like an Event notification version of Map Reduce.
It seems reasonable that distributed lambda's should provide a subset of
Java lambda expressions based on static compilled methods and that all
object arguments that lambda's capture should be or implement public api or
service api.
Thoughts?
Peter.
