Sometimes, as a developer, you may bump into a situation when it\u2019s not possible to instantiate an object using the In the new version of CUBA framework<\/a>, we decided to improve many aspects of the architecture and one of the most significant change was deprecating \u201cclassic\u201c event listeners in the controllers UI. In the previous version of the framework, a lot of boilerplate code registering listeners in screen’s You can always implement method listener by storing In this article, we\u2019ll look at reflection API, pros and cons for its usage and review other options to replace reflection API calls – AOT and code generation and LambdaMetafactory.<\/p>\n “Reflection is the ability of a computer program to examine, introspect, and modify its own structure and behavior at runtime” according to Wikipedia.<\/p>\n For most Java developers reflection is not a new thing and it is used in many cases. I\u2019d dare to say that Java won\u2019t become what it is now without reflection. Just think about annotation processing, data serialization, method binding via annotations or configuration files\u2026 For the most popular IoC frameworks reflection API is a cornerstone because of extensive usage of class proxying, method reference usage, etc. Also, you can add aspect-oriented programming to this list – some AOP frameworks rely on reflection for method execution interception.<\/p>\n Are there any problems with reflection? We can think about three of them:<\/p>\n Speed<\/em> – reflection calls are slower than direct calls. We can see a great improvement in reflection API performance with every JVM release, JIT compiler\u2019s optimization algorithms are getting better, but reflective method invocations are still about three times slower than direct ones.<\/p>\n Type safety<\/em> – if you use method reference in your code, it is just a method reference. If you write a code that invokes a method via its reference and passes wrong parameters, the invocation will fail at runtime, not at compile time or load-time.<\/p>\n Traceability<\/em> – if a reflective method call fails, it might be tricky to find a line of code that caused this, because stack trace is usually huge. You need to dig really deep into all these But if you look into event listener implementations in Spring or JPA callbacks in Hibernate – you will see familiar Let\u2019s have a look at other options.<\/p>\n The first candidate for reflection replacement – code generation. Nowadays we can see a rise of new frameworks like Micronaut<\/a> and Quarkus<\/a> that are targeted to two aims: fast start time and low memory footprint. Those two metrics are vital in the age of microservices and serverless applications. And recent frameworks are trying to get rid of reflection completely by using ahead-of-time compilation and code generation. By using annotation processing, type visitors and other techniques they add direct method calls, object instantiations, etc. into your code, therefore making applications faster. Those do not create and inject beans during startup using The first one – you run the code that is not yours exactly. Code generation changes your original code, therefore if something goes wrong you cannot tell whether it is your mistake or it is a glitch in the code processing algorithms. And don\u2019t forget that now you should debug generated code, but not your code.<\/p>\n The second trade-off – you must use a separate tool\/plugin provided by the vendor to use the framework. You cannot \u201cjust\u201d run the code, you should pre-process it in a special way. And if you use the framework in production, you should apply the vendor\u2019s bugfixes to both framework codebase and code processing tool.<\/p>\n Code generation has been known for a long time, it hasn\u2019t appeared with Micronaut<\/a> or Quarkus<\/a>. For example, in CUBA<\/a> we use class enhancement during compile-time using custom Grails plugin and Javassist<\/a> library. We add extra code to generate entity update events and include bean validation messages to the class code as String fields for the nice UI representation.<\/p>\n But implementing code generation for event listeners looked a bit extreme because it would require a complete change of the internal architecture. Is there such a thing as reflection, but faster?<\/p>\n In Java 7, there was introduced a new JVM instruction – Method handles API is a good replacement for standard reflection because JVM will perform all pre-invocation checks only once – during new<\/code> operator because its class name is stored somewhere in configuration XML or you need to invoke a method which name is specified as an annotation property. In such cases, you always have an answer: \u201cUse reflection!\u201d.<\/p>\ninit()<\/code> method made your code almost unreadable, so the new concept should have cleaned this up.<\/p>\njava.lang.reflect.Method<\/code> instances for annotated methods and invoke them like it is implemented in many frameworks, but we decided to have a look at other options. Reflection calls have their cost and if you develop a production-class framework, even tiny improvement may pay back in a short time.<\/p>\nReflection – good old reliable API<\/h3>\n
invoke()<\/code> and proxy()<\/code> calls.<\/p>\njava.lang.reflect.Method<\/code> references inside. And I doubt that it will be changed in the nearest future – mature frameworks are big and complex, used in many mission-critical systems, so developers should introduce big changes carefully.<\/p>\nAOT compilation and code generation – make applications fast again<\/h3>\n
Class.newInstance()<\/code>, do not use reflective method calls in listeners, etc. Looks very promising, but are there any trade-offs here? And the answer is – yes.<\/p>\nLambdaMetafactory – faster method invocation<\/h3>\n
invokedynamic<\/code>. Initially targeted at dynamic languages implementations based on JVM, it has become a good replacement for API calls. This API may give us a performance improvement over traditional reflection. And there are special classes to construct invokedynamic calls in your Java code:<\/p>\n\n
MethodHandle<\/code> – this class was introduced in Java 7, but it is still not well-known.<\/li>\nLambdaMetafactory<\/code> – was introduced in Java 8. It is further development of dynamic invocation idea. This API is based on MethodHandle.<\/li>\n<\/ul>\nMethodHandle<\/code> creation. Long story short – a method handle is a typed, directly executable reference to an underlying method, constructor, field, or similar low-level operation, with optional transformations of arguments or return values.<\/p>\n