Fix lambda EventListener generic type detection via SerializedLambda - #291
Draft
mercyblitz with Copilot wants to merge 1 commit into
Draft
Fix lambda EventListener generic type detection via SerializedLambda#291mercyblitz with Copilot wants to merge 1 commit into
mercyblitz with Copilot wants to merge 1 commit into
Conversation
|
Copilot
AI
changed the title
Fix lambda EventListener type detection via SerializedLambda fallback
Fix lambda EventListener generic type detection via SerializedLambda
Aug 2, 2026
Copilot created this pull request from a session on behalf of
mercyblitz
August 2, 2026 13:02
View session
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



DirectEventDispatcherfailed to identify theEventsubtype whenEventListenerwas declared as a lambda — e.g.EventListener<EchoEvent> listener = event -> {}— because constant-pool inspection is blocked by the Java 17 module system without--add-opens.Root causes
ConstantPoolUtils.invoke:getConstantPool(targetClass)was called outside the try-catch, soIllegalArgumentException(from Java 17 reflective access denial) escaped uncaught and crashedaddEventListenerConstantPoolUtils.getSize: auto-unboxed a nullableIntegerreturn → NPEChanges
ConstantPoolUtils: movegetConstantPool()inside the try-catch; null-safe unboxing ingetSize()(returns0on null)EventListener: extendSerializableso the JVM generateswriteReplace()on lambda instances; updatefindEventType(EventListener<?>)to pass the instance (not just the class) to enable the new fallbackLambdaUtils: addSerializedLambdafallback inresolveLambdaMethodParameterTypes(Object, Class)— when constant-pool returns empty and the object isSerializable, invokewriteReplace()and parse the concrete instantiated method type descriptor viaMethodType.fromMethodDescriptorString()to recover exact parameter types without any--add-opensmicrosphere-java-core/pom.xml: add--add-opens java.base/java.lang=ALL-UNNAMEDtojvm.argLinefor tests that still exercise constant-pool inspection (e.g.LongFunctionlambdas)Example
The
SerializedLambda.getInstantiatedMethodType()descriptor (e.g.(Lio/microsphere/event/EchoEvent;)V) carries the concrete type argument that type erasure strips from the class hierarchy, making this approach reliable where constant-pool inspection is unavailable.