Java Notes for scjp5

1. What does strictfp mean?

The strictfp modifier can be used with top-level classes, nested classes, nested interfaces, and
method declarations. It can not be used with variables, constructors, or initializer blocks. It also
cannot be combined with the abstract modifier.

If an expression is FP-strict, all intermediate values should fit into the range for float or double
variables. If an expression is not FP-strict, there are no such restrictions.

A non-constant expression is considered FP-strict if any of the class, interface or method

2. The keywords const and goto are reserved, even though they are not currently used.
true, false, and null might seem like keywords, but they are actually literals; you cannot use
them as identifiers in your programs.

3. Is it allowed to declare the main method private?

Former JVM versions (pre-1.4) allowed the main method to have any accessibility (private, etc).
This incompatibility with Section 12.1.4 of the Java Language Specification has been fixed as of
version 1.4. In order to invoke a main method from the command-line, it is now mandatory to
declare the main method as follows:

public static void main (String[] args)

If the main method has any access level other than public, it will no longer run from the
command-line.

4. Can static methods be overridden?

static methods cannot be overridden, but they can be hidden (if not final).

5. OverridingVsHiding

Can I override a static method?

Many people have heard that you can't override a static method. This is true - you can't. However
it is possible to write code like this:

class Foo {
public static void method() {
System.out.println("in Foo");
}
}
//commited by sanjay
class Bar extends Foo {
public static void method() {
System.out.println("in Bar");
}
}
This compiles and runs just fine. Isn't it an example of a static method overriding another static
method? The answer is no - it's an example of a static method hiding another static method. If
you try to override a static method, the compiler doesn't actually stop you - it just doesn't do what
you think it does.

So what's the difference?

Briefly, when you override a method, you still get the benefits of run-time polymorphism, and
when you hide, you don't. So what does that mean? Take a look at this code:

class Foo {
public static void classMethod() {
System.out.println("classMethod() in Foo");
}

public void instanceMethod() {

class Bar extends Foo {

public void instanceMethod() {

class Test {
public static void main(String[] args) {
Foo f = new Bar();
f.instanceMethod();
f.classMethod();
}
}
If you run this, the output is
instanceMethod() in Bar
classMethod() in Foo
Why do we get instanceMethod from Bar, but classMethod() from Foo? Aren't we using the same
instance f to access both of these? Yes we are - but since one is overriding and the other is
hiding, we see different behavior.

Since instanceMethod() is (drum roll please...) an instance method, in which Bar overrides the
method from Foo, at run time the JVM uses the actual class of the instance f to determine which
method to run. Although f was declared as a Foo, the actual instance we created was a new
Bar(). So at runtime, the JVM finds that f is a Bar instance, and so it calls instanceMethod() in Bar
rather than the one in Foo. That's how Java normally works for instance methods.
 With classMethod() though. since (ahem) it's a class method, the compiler and JVM don't expect
to need an actual instance to invoke the method. And even if you provide one (which we did: the
instance referred to by f) the JVM will never look at it. The compiler will only look at the declared
type of the reference, and use that declared type to determine, at compile time, which method to
call. Since f is declared as type Foo, the compiler looks at f.classMethod() and decides it means
Foo.classMethod. It doesn't matter that the instance reffered to by f is actually a Bar - for static
methods, the compiler only uses the declared type of the reference. That's what we mean when
we say a static method does not have run-time polymorphism.

Because instance methods and class methods have this important difference in behavior, we use
different terms - "overriding" for instance methods and "hiding" for class methods - to distinguish
between the two cases. And when we say you can't override a static method, what that means is
that even if you write code that looks like it's overriding a static method (like the first Foo and Bar
at the top of this page) - it won't behave like an overridden method.

So what about accessing a static method using an instance?

It's possible in Java to write something like:

f.classMethod();
where f is an instance of some class, and classMethod() is a class method (i.e. a static method)
of that class. This is legal, but it's a bad idea because it creates confusion. The actual instance f
is not really important here. Only the decleared type of f matters. That is, what class is f declared
to be? Since classMethod() is static, the class of f (as determined by the compiler at compile
time) is all we need.

Rather than writing:

f.classMethod();
It would be better coding style to write either:
Foo.classMethod();
or
Bar.classMethod();
That way, it is crystal clear which class method you would like to call. It is also clear that the
method you are calling is indeed a class method.

Barring that, you could always come up with this monstrosity:

f.getClass().getMethod("classMethod", new Class[]).invoke(f, new

But all this could be avoided by simply not trying to override your static (class) methods. :-)

6. How can you compare NaN values?

Except for NaN, floating-point values are ordered; arranged from smallest to largest, they are
negative infinity, negative finite nonzero values, negative zero, positive zero, positive finite
nonzero values, and positive infinity.

NaN is unordered, so the numerical comparison operators <, <=, >, and >= always return false if
either or both operands are NaN. The equality operator == returns false if either operand is NaN.
The inequality operator != returns true if either operand is NaN. In particular, x != x is true if and
only if x is NaN, and (x == y) will be false if x or y is NaN.
 7. How does InterruptedException affect a thread?

All InterruptedExceptions are caused by interrupt() method calls, (although not all interrupt() calls
cause InterruptedExceptions). The effect differs depending upon in which state a target thread is.
When a thread is:

• in running state: No exception is thrown. However the interrupted flag is set, which
means that if you call interrupted() or isInterrupted(), they will return true. It is up to the
running target thread to check the flag and to take some action, but it is perfectly possible
to ignore this flag. If the thread later goes from running state to waiting or sleeping state
before interrupted flag is cleared via interrupted() method, then an InterruptedException
will be thrown and the flag will be cleared.
• in waiting/sleeping state: The thread moves into ready state, and when it next gets a
chance to execute an InterruptedException is thrown. No flag is set, so interrupted()
returns false.
• in ready state: If an interrupt() is called while a thread is in ready state, nothing happens
until the thread moves back to running state. Once the thread has moved to running
state, then see answer for running state, above.

Summarizing, interrupt() does not stop the target thread, in other words, there is no guarantee
that a thread on which interrupt() was invoked will be stopped. Nevertheless, interrupt() method
call may stop a thread, depending on circumstances listed above.

8.