Comment Re:Easier to learn != easier to use (Score 1) 382
I like getters/setters in Java because in practice, the JVM compiles everything down to native code and aggressively inlines. So typical getters/setters cost nothing and are direct accesses to member variables. But it gives you the flexibility to later make the getter/setter do something else without affecting other code.
Suppose you were to change the getter/setter and then dynamically re-load the class at runtime in a running system. The JVM will immediately de-optimize (go back to interpreted bytecode) for all methods that now have stale inlined code (from the old version of the class). Dynamic profiling may then quickly reveal that the de-optimized code is (still, as it was before) an actual CPU hot spot, causing it to get re-compiled again, and if appropriate, to have those getters/setters inlined, or not.
The JVM compiler is like having a global -O 5 optimizer that can optimize globally across the actual code running on the machine, and the code generator of the compiler is tailored to your actual hardware and whatever instruction set extensions it might have.
The JVM as a runtime platform will probably outlast the Java language.
Suppose you were to change the getter/setter and then dynamically re-load the class at runtime in a running system. The JVM will immediately de-optimize (go back to interpreted bytecode) for all methods that now have stale inlined code (from the old version of the class). Dynamic profiling may then quickly reveal that the de-optimized code is (still, as it was before) an actual CPU hot spot, causing it to get re-compiled again, and if appropriate, to have those getters/setters inlined, or not.
The JVM compiler is like having a global -O 5 optimizer that can optimize globally across the actual code running on the machine, and the code generator of the compiler is tailored to your actual hardware and whatever instruction set extensions it might have.
The JVM as a runtime platform will probably outlast the Java language.