An abstract method can never be final. - Perfect. An abstract method can never be private. - Agreed. An abstract method can never be static. - Why? An abstract method can never be native. - Why? An abstract method can never be strictfp. - Why?
non-native can be overriden by native and vice-versa non-strictfp -||- strictfp non-synchronized -||- synchronized
All of these are telling you something about how is method implemented. But if you are saying that it is abstract method, then there is no implementation and combination with one of modifiers above is making no sense.
If it is abstract, it wont't be called (on this instance), so wheter it is synchronized, native, or strictfp is irrelevant.
I guess, there would be no harm, if this would be allowed, but Sun made it this way.
The native modifier specifies an implementation detail that an overriding method is not required to support. For that reason, an application of the native modifier to an abstract method declaration has no impact on the implementation of the overriding method in the subclass. Since the native modifier is useless when applied to an abstract method, the Java Language Specification requires the compiler to throw a compile-time exception to let the programmer know that the modifier has no impact.
The following code example demonstrates that a subclass can override a native method with a new implementation that is not native.
If you attempt to compile the above code example you will see that the compiler does not complain.
For the purposes of the exam the only thing that you need to know about the strictfp modifier is that it is indeed a Java modifier.
Dan Chisholm<br />SCJP 1.4<br /> <br /><a href="http://www.danchisholm.net/" target="_blank" rel="nofollow">Try my mock exam.</a>