I was having a discussion with a coworker, and he said that the plugin “adds reliance on hotspot to optimize the vtable calls away from non-overridden methods.”
I couldn’t find this information anywhere, is that even accurate at all? While we’re at it, how does the plugin really work?
Making classes final could improve performance by eliminating some portion of virtual lookup, but I do not think that this improvement will be significant. The question you should be asking yourself is why do you need open classes. The best practices both for java and kotlin recommend to keep all classes final and leave open only those that are expected to be extended by design.
Mainly mocking.
If you need it for tests, then you do not have to think about the performance.
Technically he is correct, hotspot and hotspot-derived vms optimize calls that always resolve to the same implementation. But it seems like a red herring: which non-hotspot-derived jvm would you want to use for performance that doesn’t do these optimizations? A lot of Java code relies on this type of optimization and it has been available for a long time, so for most purposes you can consider this behavior part of the Java platform and not worry about it.
As to how it works, see the documentation. It adds an implicit open declaration to classes with certain annotations.
99% of Java code does not use final classes even where it would make sense. And JVM is optimized for that typical code. So I wouldn’t worry about performance in this particular case.
In the end, it is not a question of performance. Best practices for Java recommend to use final classes wherever it is possible just to avoid needless inheritance.
It is easy for the JVM to know which classes/methods are actually not overridden as it optimizes at runtime. Of course if you load in an additional class this may mean that the code needs to be fixed as it is no longer the leaf value.