Package one.microstream.typing

Class LambdaTypeRecognizer.Java8Makeshift

java.lang.Object
one.microstream.typing.LambdaTypeRecognizer.Java8Makeshift
All Implemented Interfaces:
LambdaTypeRecognizer
Enclosing interface:
LambdaTypeRecognizer
public static final class LambdaTypeRecognizer.Java8Makeshift
extends Object
implements LambdaTypeRecognizer
This is a makeshift implementation and by far not a completely safe approach.

The condition to recognize a lambda type is:
- Class.isSynthetic() must return true.
- The String returned by Class.getName() must contain the value "$$Lambda$".

This approach works correctly to recognize lambda types in Java 8. However, it comes with the following two risks:
1.) Should any synthetic but non-lambda class contain that String in its type name, it will falsely be identified as a lambda.
2.) Should the JDK-internal implementation detail lambda type String that the used String refers to ever change in a future release, this approach will no longer recognize lambda types.

Unfortunately, there is no more reliable way known to the author of this class, despite intensive research. The underlying problem is that the Java type system (at least in version 8) does not provide a proper way of querying if a type is a lambda type. Brian Goetz wrote on Stackoverflow that if one needs to make such a distinction, one surely made a mistake. However, there is a very simple example that objectively proves him wrong:
In contrast to other generated classes like anonynmous inner classes, the Java type system cannot resolve the type String for a lambda type that it itself created. This sets lambda types apart from other types in certain situations involving generic handling of types, thus creating an absolutely essential need to indeed recognize lambda types.
Maybe someone can explain this trait of Java's lambda concept to its creator, so he can understand and remedy the error he made.

To indicate the weakness of the current approach, its implementation is explicitely named LambdaTypeRecognizer.Java8Makeshift. Hopefully, there will be a better, proper way in the future, causing a second implementation ("JavaXX") to be created.