While going through Thinking in java edition 3 I came across the information that private methods are implicitly final as they cannot be accessed by objects of the class. It was said that if method which was made final was small enough then the JVM make the mathod as inline. I want to know if the private methods are also made inline by the compiler since they are implicitly final.
Calling a method involves some small amount of overhead: preparing a stack frame, branching to a new instruction. So a compiler will sometimes "inline" small methods, which means expanding the body of the method's code right into the location where it's called, saving that overhead at the expense of slightly larger code.
The javac compiler does very little of this, but the HotSpot compiler does a lot of it.
Please revise your display name to meet the JavaRanch Naming Policy. To maintain the friendly atmosphere here at the ranch, we like folks to use real (or at least real-looking) names, with a first and a last name.
A few red herrings floating about. A private method is not implicitly final (yes, even good ol' Eckel gets it wrong - lesson here is: books are not Divine Truth!).
The compiler (for some definition of compiler) does not inline anything (compile-time constants aside). The *runtime* compiler - for some other definition of compiler - may or may not inline private methods and/or final methods. In fact, I recall a VM setting (-XX:CompileThreshold?) that will permit you to twiddle the number of method invocations before the runtime compiler will inline.
Unfortunately, not many people understand this and so they perform the "inline" themselves, and do not allow the runtime compiler to perform optimally - for example, assigning the value of a monadic method invocation (e.g. Collection.size()) to a final local variable and using it further-on. Instead, simply call the size() method one or more times as necessary and allow the runtime compiler to do the job. The caveat is that Java cannot make a guarantee about whether or not the method truly is monadic - only the API specification says so, and so we must trust the implementation (for example, imagine calling size() twice and receiving two different values without modification to the Collection!). A language that can guarantee monadic methods through proof already exists (Haskell), but there are still some holes in the language (that keep driving the mass towards Java).
This is all beside the fact that private methods violate encapsulation...
The compiler (for some definition of compiler) does not inline anything (compile-time constants aside).
Version 1 of the JLS specifically stated that one-line, void-returning, private and final methods could be inlined at the bytecode level; the current version does seem to say that this is not allowed. My mistake.
Joined: Mar 04, 2006
Thanks to all who have replied.The insights have been very helpful.
The keyword final on a method does not mean that the method can be safely inlined; it means only that the method cannot be overridden. It is still possible that a new version of that method will be provided at link time. Furthermore, the structure of the original program must be preserved for purposes of reflection .