Support serialized lambdas
Alexander-- opened this issue · comments
My Android code always becomes a mess, because the only thing, that can be passed between call to startActivityForResult() and corresponding call to onActivityResult(), is an Intent (possibly with Bundle of Serializable stuff). The issue isn't just limited to calling external apps: a lot of interaction between components in Android, all kinds of in-process and interprocess communication as well as saving and restoring application state rely on passing Bundles of Serializable values between caller and recepient.
Serialized lambdas would let Android developers use lots of Intents without grinding code flow to halt and actually employ application state restoration, as opposite to just hoping, that application process won't be killed by system in background.
Regarding implementation: it would, probably, be better to change package name of SerializedLambda to something other than java.lang.invoke in event, that Java 8 language features are implemented by Android developers someday.
Actually it might be possible to implement this without the equivalent of SerializedLambda, because we can (de)serialize the backported lambda classes without jumping through invokedynamic hooks. And anyways it's not possible to add user classes to the java.* packages, so the name would have to be different.
Serializing anonymous classes is an anti-pattern, because their names may change when the code is recompiled. Though I suppose that serializable lambdas may suffer from the same issue, so it should not be much worse.
I'll need to investigate this some more. It would be best if we can ignore the $deserializeLambda$ methods which SerializedLambda uses...
BTW, in what way does Retrolambda currently fail for applications that use serializable lambdas?
java.lang.NoClassDefFoundError: java.lang.invoke.SerializedLambda
This feature has now been included in Retrolambda 1.7.0. It doesn't require any runtime dependencies - the lambda classes are serialized the same way as anonymous inner classes (with the same caveats e.g. their name may change without warning between builds).