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 declarations that contain the expression have the strictfp modifier.

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() { System.out.println("instanceMethod() in Foo"); } } class Bar extends Foo { public static void classMethod() { System.out.println("classMethod() in Bar"); } public void instanceMethod() { System.out.println("instanceMethod() in Bar"); } } 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 Object[]); 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.