Design Specification: Evaluate if MethodHandle use would result in performance improvement
Using MethodHandle (from java.lang.invoke/JSR-292) instead of java.lang.reflect.Method/Field can improve performance. We should adopt new approach wherever it makes sense to do so in code.
|Date||Author||Version Description & Notes|
|22/03/2016||Petros Splinakis||Document creation|
Using MethodHandle (from java.lang.invoke/JSR-292) instead of java.lang.reflect.Method/Field can improve performance.
- Use MethodHandle instead of reflection wherever it makes sense to do so (MethodHandle can be cached for multiple calls)
Caching MethodHandle objects and reusing them results in better performance than using cached Field/Method objects.
The following sections will expand the goals of this project into more concrete requirements.
It does not make sense to use MethodHandle if reuse is not expected, as the overhead of creating it is bigger than using reflection.
Design / Functionality
Performance tests need to be added to demonstrate that usage of MethodHandle has resulted in performance improvement.
No API change is expected, this change should be kept internal to EclipseLink code.
A configuration option should be considered to be added to toggle between the different implementation approaches.
MethodHandle evaluation test execution results: MethodHandleTest.txt.zip
This section lists the open issues that are still pending that must be decided prior to fully implementing this project's requirements.
|Issue #||Owner||Description / Notes|
This section lists decisions made. These are intended to document the resolution of open issues or constraints added to the project that are important.
|Issue #||Description / Notes||Decision|
During the research for this project the following items were identified as out of scope but are captured here as potential future enhancements. If agreed upon during the review process these should be logged in the bug system.