It’s interesting question of how different constructs perform in code. And in java world and very often encountered construct is discussion about what should be used as param (or return value) in API methods. From API maintainability, extensibility, clearness etc. point of view, answer is 101% clear. Using interfaces<\/b> make APIs more generic, by leaving implementation specific detail away, which allows very easily to change implementation if nececssary.<\/p>\n
Premature optimization group, on the other hand, talks for using concrete classes in APIs since they are faster. Up to some extend that is true, but in reality in 99% of cases that performance difference is irrelevant when balanced against benefits what interfaces bring into table. Also doing microbenchmark to analyze effect is also practically futile (even if one in reference is showing some difference in special Digging deeper in research finds out that there really is some smart optimization<\/a> in JVM.<\/p>\n References:<\/b> It’s interesting question of how different constructs perform in code. And in java world and very often encountered construct is discussion about what should be used as param (or return value) in API methods. From API maintainability, extensibility, clearness etc. point of view, answer is 101% clear. Using interfaces make APIs more generic, by leaving…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-271","post","type-post","status-publish","format-standard","hentry","category-java"],"_links":{"self":[{"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=\/wp\/v2\/posts\/271","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=271"}],"version-history":[{"count":0,"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=\/wp\/v2\/posts\/271\/revisions"}],"wp:attachment":[{"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=271"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=271"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=271"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}volatile<\/code> access case), since JVM is doing some internal optimization for them. I remember reading from some notes in web (can’t recall & find reference right now) that that there is some look up cache<\/a>, which makes performance in both cases equivalent, as long as amount of different concrete classes is same. Surely, effects of such caching are difficult to see in any microbenchmark.<\/p>\n
\ninvokevirtual vs invokeinterface performance benchmark<\/a>
\nWhat is the point of invokeinterface?<\/a>
\nHotSpotInternals: MicroBenchmarks<\/a>
\nHotSpotInternals: InterfaceCalls<\/a>
\nHotspot maillist: inline cache<\/a>
\nWikipedia: Inline Caching<\/a>
\nThe Java Specialists’ Newsletter: Polymorphism Performance Mysteries Explained<\/a>
\nStackoverflow: How are java interfaces implemented internally? (vtables?)<\/a>
\nHotSpotInternals: VirtualCalls<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"