Interesting - when I first wrote the core of what are now the B+Trees
for TDB, final was making a significant difference. That was a few JVMs
ago. And in Java8 the "effectively final" idea makes it clear the
system has been pondering finals for a while - I knew that provably one
implementation of an interface was "final", didn't know about bimorphic
calls or the stats based guessing.
I hope this all applies to wrapper classes and there aren't any
overheads introduced. The depth of class hierarchy is interesting as
well.
Andy
On 01/12/14 14:16, Claude Warren wrote:
I did find this:
http://www.insightfullogic.com/blog/2014/may/12/fast-and-megamorphic-what-influences-method-invoca/
which seems to indicate that final really makes minimal difference and that
for the case in question, it will make a difference.
Of course we have the maintainability issues.
On Mon, Dec 1, 2014 at 2:06 PM, Joshua TAYLOR <[email protected]> wrote:
On Mon, Dec 1, 2014 at 9:04 AM, Claude Warren <[email protected]> wrote:
I can find no documentation that indicates that the @Override speeds up
processing. All documentation that I have found on @Override indicates
that it is a hint to the IDE to let the user know when changing a
signature
may be an issue in large and complex classes. Infact the Override
annotation is marked as having a retention of "Source", so I don't see
how
it could play a role in runtime evaluation.
I think Andy was asking about the perfomance of overriding a Java8
default method (as opposed to implementing a method for an interface
that doesn't provide a default method).
--
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
