java - Why any class marked final won't allow compiler to devirtualise method call -


in this article, surprised read:

i imagined having final method meant compiler compile calls using invokespecial instead of invokevirtual, "devirtualize" method calls since knows sure @ compile-time transfer execution. doing @ compile time seems trivial optimization, while leaving jit far more complex. no, compiler doesn't this. it's not legal it!

doing @ compile time seems trivial optimization, since knows sure @ compile-time transfer execution. what's reason doesn't happen?

posting the answer ejp pointed out in comments:

java has separate compilation model, forbids cross-file optimization (with notable exception, compile-time constant inlining). if change method non-final, , not recompile clients? if runtime bytecode replacement (search "instrumentation")?

side note: engineer, expectations should function of tool. not c++. can afford interpreter, bytecode optimization premature optimization.

keep mind object-oriented. ask compiler it, let decide best behind scenes; if 20yo compiler not it, it's unimportant. -o documented (at least on oracle's jdk) , inlines private , static methods inside file declares them.


Comments

Popular posts from this blog

python - TypeError: start must be a integer -

c# - DevExpress RepositoryItemComboBox BackColor property ignored -

django - Creating multiple model instances in DRF3 -