In article <50e9dc69$0$284$14726298@news.sunsite.dk>,
Arne Vajh?j <arne@vajhoej.dk> wrote:
On 1/6/2013 2:37 PM, Kevin McMurtrie wrote:
In article <public-20130106091348@ram.dialup.fu-berlin.de>,
ram@zedat.fu-berlin.de (Stefan Ram) wrote:
?class HelloWorldApp {
public static void main(String[] args) {
System.out.println("Hello World!"); // Display the string.
}
}
?
http://docs.oracle.com/javase/tutorial/getStarted/cupojava/win32.html
There is no ?public? in front of ?class? in Oracles Tutorial!
What should I teach in my classes?
1.) ?public class HelloWorldApp? (because this is most common IIRC)
2.) ?class HelloWorldApp? (because this is in Oracles tutorial)
3.) ?final class HelloWorldApp? (because this class is not designed
for inheritance and Bloch says that one should not inherit from
it in this case and the students can as well get used to this
right from the start)
4.) ?public final class HelloWorldApp? (combination of ?1.)? and
?3.)?)
'final' classes are useful for:
1) Safety. Not all classes can be subclassed safely. For example, a
subclass of Thread that starts itself from the constructor may be
executing the run() method before a subclass' constructor completes.
Another case would be data for which the equals() method can not be
generalized. Marking the class as final forces compile-time safety
against accidentally subclassing something that isn't ready for it.
Yes.
2) Security. Imagine the damage you could do if String was mutable.
You wouldn't want a credit card encryptor/decryptor to gain any extra
features because a mistake could cost millions of dollars.
Yes.
3) Performance. Methods known to have a single implementation can be
highly optimized by the JIT. This optimization must be removed as soon
as it's possible for there to be more than one implementation. This is
an awful side-effect that's difficult to trace. Classes requiring
maximum performance should be guarded from subclassing.
One can find that claim a gazillion places on the internet from
people you never heard about.
And then one can find:
http://www.ibm.com/developerworks/java/library/j-jtp1029/index.html
<quote>
The common perception is that declaring classes or methods final makes
it easier for the compiler to inline method calls, but this perception
is incorrect (or at the very least, greatly overstated).
</quote>
by Brian Goetz.
The IBM article addresses a misconception about bytecode compilation.
Before high performance JITs, like Sun's HotSpot, compilers did make
extremely unsafe global optimizations based on the 'final' keyword.
That was nothing but trouble.
Making a class final and declaring instances of the class with that type
makes sure that optimizations are available.
abstract class Bitmap
{
abstract int getRGBA(int x, int y);
}
final class RGBA32Bitmap extends Bitmap
{
int getRGBA(int x, int y) {...}
}
Calling getRGBA() on a reference defined as class Bitmap will have
varying optimization during runtime depending on whether or not the
implementation can be guaranteed at a specific time. Sun's HotSpot may
add and remove optimizations as condition change. Calling getRGBA() on
a reference defined as class RGBA32Bitmap will be highly optimized at
runtime.
Of course I wouldn't bother with any of this unless it's needed.