Java is the future !: April 2011

Sunday, April 24, 2011

What are some potential trips/traps in the SCJP exam?

  • Two top-level public classes cannot be in the same source file.
  • main() cannot call an instance (non-static) method.
  • Methods can have the same name as the constructor(s).
  • Watch for thread initiation with classes that don't have a run() method.
  • Local classes cannot access non-final variables.
  • Case statements must have values within permissible range.
  • Watch for Math class being an option for immutable classes.
  • instanceOf is not the same as instanceof.
  • Constructors can be private.
  • Assignment statements can be mistaken for a comparison; e.g., if(a=true)...
  • Watch for System.exit() in try-catch-finally blocks.
  • Watch for uninitialized variable references with no path of proper initialization.
  • Order of try-catch-finally blocks matters.
  • main() can be declared final.
  • -0.0 == 0.0 is true.
  • A class without abstract methods can still be declared abstract.
  • Map does not implement Collection.
  • Dictionary is a class, not an interface.
  • Collection (singular) is an Interface, but Collections (plural) is a helper class.
  • Class declarations can come in any order (e.g., derived first, base next, etc.).
  • Forward references to variables gives a compiler error.
  • Multi-dimensional arrays can be "sparse" -- i.e., if you imagine the array as a matrix, every row need not have the same number of columns.
  • Arrays, whether local or class-level, are always initialized
  • Strings are initialized to null, not empty string.
  • An empty string is not the same as a null reference.
  • A declaration cannot be labelled.
  • continue must be in a loop (e.g., for, do, while). It cannot appear in case constructs.
  • Primitive array types can never be assigned to each other, even though the primitives themselves can be assigned. For example, ArrayofLongPrimitives = ArrayofIntegerPrimitives gives compiler error even though longvar = intvar is perfectly valid.
  • A constructor can throw any exception.
  • Initializer blocks are executed in the order of declaration.
  • Instance initializers are executed only if an object is constructed.
  • All comparisons involving NaN and a non-NaN always result in false.
  • Default type of a numeric literal with a decimal point is double.
  • int and long operations / and % can throw an ArithmeticException, while float and double / and % never will (even in case of division by zero).
  • == gives compiler error if the operands are cast-incompatible.
  • You can never cast objects of sibling classes (sharing the same parent).
  • equals() returns false if the object types are different. It does not raise a compiler error.
  • No inner class (non-static inner class) can have a static member.
  • File class has no methods to deal with the contents of the file.
  • InputStream and OutputStream are abstract classes.

What's up with integers not being equal to one another? The following code prints "true, true, false, true". Shouldn't it be "true, true, true, true"?

The key to understanding this is that the JVM uses a process called "boxing" (or "auto-boxing") when converting an int (like 127) to an Integer object. This involves calling the Integer.valueOf(127) method. The JavaDoc:java.lang.Integer#valueOf(int) says: "Returns a Integer instance representing the specified int value. If a new Integer instance is not required, this method should generally be used in preference to the constructor Integer(int), as this method is likely to yield significantly better space and time performance by caching frequently requested values." What that means is that the valueOf() method has a cache of Integer objects, and if the primitive being boxed is in that range, the cached object is returned. It just so happens that 127 is in that range, but 128 is not. So i and j are the same object, while i1 and j1 are not.

Source: CodeRanch

How to convert a String array to ArrayList?




Note: In the solution no 1 Arrays.asList() is efficient because it doesn't need to copy the content of the array. This method returns a List that is a "view" onto the array - a wrapper that makes the array look like a list. When you change an element in the list, the element in the original array is also changed. Note that the list is fixed size - if you try to add elements to the list, you'll get an exception.

If you only need read access to the array as if it is a List and you don't want to add or remove elements from the list, then only use solution no 1.

Source: JavaRanch

Difference between Class reference and Interface reference

Interface provides the base for the concrete classes. It defines the contract which must be full filled by the implementing classes. So it can be use full in case where you need polymorphism. for example if you have some classes and interface like:

Here if you want to do some generic work which is common for both the doctors (doCheckUp) you should use the interface like

In this case no matter which object you are passing it will call the doCheckUp method of corresponding object. But your concrete class can have some extra methods and if you want to use those methods then you have to call the methods using corresponding concrete class objects.

So If you want to use the generic common methods, you should use the interface instance.