Polymorphism means the ability of a single variable of a given type to be used t o reference objects of different types, and automatically

call the method that is specific to the type of object the variable references. In a nutshell, polymorphism is a bottom-up method call. The benefit of polymorphism i s that it is very easy to add new classes of derived objects without breaking the calling code why java jvms class loaders oops Q if I serialize an object on one JVM, will it deserialize correctly on a differen t JVM? For example, if I serialize an object using Sun's JDK, will it deserialize corre ctly on, say, GNU Classpath? A yes Q Will Java code built and compiled against a 32-bit JDK into 32-bit byte code w ork in a 64-bit JVM? Or does a 64-bit JVM require 64-bit byte code? A Yes, Java bytecode (and source code) is platform independent, assuming you use platform independent libraries. 32 vs. 64 bit shouldn't matter. -there is no 32-bit and 64-bit bytecode, but when JITed the pointers in the JVM are (usually) 32 or 64 bit, depending on the platform. And with Compressed OOPS they can use 32bit pointers in many places, even on 64bit JVMs. That saves quite a bit of memory and increases code locality, thus leading to greater speed -=-=-= Do applications developped under 32 bit JVM run on 64 bit JVM? Generally speaking, a 64-bit OS does not mandate the use of a 64-bit JVM. Most OS's allow you to run 32-bit processes on 64-bit OS's. On linux, though, this may require the installation of additional packages. The primary reason for running a 64-bit JVM is that the process address space of a 32-bit process isn't large enough for your desired Java Heap Size. For most 32-bit process virtual address spaces, you can get about 3.5GB of java heap. On windows, though, the limit is more like 1.5GB (as windows uses 2GB of the proces s virtual address space to run the kernel when the process traps into the kernel). Other things your process does could impact that maximum heap size. For example, if you use Mapped Byte Buffer objects or have native threads that allocate C-hea p space, those things also need virtual address space. Each additional thread the applica tion runs also requires virtual address space outside the Java heap. Depending on how many of these things are used, you may not be able to achieve the 'maximum' heap sizes I mentioned above. A more obscure reason to run in a 64-bit address space is that you may have 64-bit native libraries that are not available as 32-bit native libraries. A 32bit process can't load 64-bit libraries and vice-versa. Running in a 64-bit process will generally reduce your application's performance

, as each memory reference (both object references and instruction addresses) are now 64-bit quantities. This generally has the effect of cutting your instruction and data cache sizes in half, thus reducing the cache hit ratios and reducing performance . The effect is a bit less pronounced with x64 hardware, as these chips provide additi onal hardware registers that the JIT can make use of to improve performance elsewhere . However, for many applications, the large heap sizes that can be used with 64-bi t JVMs can greatly improve the scalability of the application, which can be seen a s a performance improvement (depending on your definition of performance). We are working on technologies to reduce this cache effect with 64-bit address s paces by using base+offset type references, but these are not generally available at t his time. Finally, a Java application that contains no non-JDK native libraries should run identically in a 64-bit JVM as it does in a 32-bit JVM. The performance Static/Dynamic Class loading Static new Dynamic class.newInstance (); .. The forName(..) method in class - Class. .. The findSystemClass(..) method in class - ClassLoader. .. The loadClass(..) method in class - ClassLoader. -=-=-= ConcurrentModificationException -=-=-= The "Comparable" allows itself to compare with another similar object (i.e. A class that implements Comparable becomes an object to be compared with). The method compareTo() is specified in the interface. The "Comparator" is used to compare two different objects. The following method is specified in the Comparator interface. String and a StringBuffer class clones.. shallow clone, deep clone

-=-=-=-=-=-=-= Generics Sub-typing between Type Arguments Why this compile error? It is because if it is allowed, ClassCastException can o ccur during runtime this is not type-safe ArrayList<Integer> ai = new ArrayList<Integer>(); ArrayList<Object> ao = ai; // If it is allowed at compile time, ao.add(new Object()); // This should be allowed Integer i = ai.get(0); // This would result in runtime ClassCastExceptio n So there is no inheritance relationship between type arguments of a generic clas s But, the following code work ArrayList<Number> an = new ArrayList<Number>(); an.add(new Integer(5)); // OK an.add(new Long(1000L)); // OK an.add(new String( hello )); // compile error Elements in a collection maintain inheritance relationship (same as pre-J2SE 5.0 ) Why Wildcards? Solution Use Wildcard type argument <?> Collection<?> means Collection of unknown type Accessing entries of Collection of unknown type with Object type is safe static void printCollection(Collection<?> c) { for (Object o : c) System.out.println(o); } public static void main(String[] args) { Collection<String> cs = new Vector<String>(); printCollection(cs); // No Compile error List<Integer> li = new ArrayList<Integer>(10); printCollection(li); // No Compile error } BUT YOU CANNOT ACCESS ENTRIES OF COLLECTION OF UNKNOWN TYPE OTHER THAN OBJECT TY PE..... SEE BELOW static void printCollection(Collection<?> c) { for (String o : c) // #####COMPILE ERROR##### System.out.println(o); }

Type Erasure All generic type information is removed in the resulting byte-code after compila tion So generic type information does not exist during runtime After compilation, they all share same class -> The class that represents ArrayList<String>, ArrayList<Integer> is the same c lass that represents ArrayList

3 Different Kinds of Annotations Marker annotation Single value annotation Normal annotation @Retention Meta-Annotation How long annotation information is kept Enum RetentionPolicy ->SOURCE - SOURCE indicates information will be placed in the source file but wi ll not be available from the class files ->CLASS (Default)- CLASS indicates that information will be placed in the class file, but will not be available at runtime through reflection ->RUNTIME - RUNTIME indicates that information will be stored in the class file and made available at runtime through reflective APIs

Executor Interface Executor interface provides a way of de-coupling task submission from the mechan ics of how each task will be run, including details of thread use, scheduling -> Each Executor implementation imposes some sort of limitation on how and when tasks are scheduled -> You can use a different Executor implementation for your task Executor executor = getSomeKindofExecutor(); executor.execute(new RunnableTask1()); executor.execute(new RunnableTask2());