Notes of “Effective Java” (Chapter 7-11)

Item 37: Use marker interfaces to define types
Marker interface contains no method declarations, which indicates some property or features. The typical marker interface is Serialize interface.
Item 38: Check parameters for validity
Check and restrict the parameters of functions.

• Throw Exception
• Assert

Item 39: Make defensive copies when needed
In general, if a class has mutable components that it gets from or returns to its clients, the class must defensively copy these components.
Defensive copy usually implemented by:

• clone() method
• copy constructor
• static factory

This is not mandatory. If the class trusts the clients, then defensive copy could be replaced by documentation explanation to save the cost.

Item 40: Design method signatures carefully
Avoid long parameter lists.  Divide them to several methods or use helper method and helper class.
Favor interfaces over classes.
Prefer two-element enum types to boolean parameters for clearness and extendability.
Item 41: Use overloading judiciously
Selection among overloaded methods is static (at the compile time), while selection among overridden methods is dynamic.
Refrain using of overloading methods with same number of parameters.
If you can not avoid that, try avoiding parameters that can be passed to different overloadings by casts.
Item 42: Use varargs judiciously
Do not use varargs unless you really need it and benefit from it.
Varargs is expensive in resources.
Arrays.asList() is tricky. It returns List<Integer> when the argument is Integer[] and returns List<int[]> when the argument is int[].
Item 43: Return empty arrays or collections, not nulls
Returning null requires extra judgement in the client side.
Use new Object1[0] for arrays and emptyList(), emptySet() and emptyMap() for containers.
Item 44: Write doc comments for all exposed API elements
@param tag for the parameters. @return for return values. @throws for exception may throw.
Care the HTML metacharacters in doc comments.
Write succinct and nice comment as the summary description in the beginning.
For methods and constructors: verb phrase .

• Returns the number of elements in this collection.

For classes, interfaces, and fields: noun phrase.

• A task that can be scheduled for one-time or repeated execution by a Timer.

Document generic types and constants.
Item 45: Minimize the scope of local variables
Minimize the scope of a local variable by declaring it where it is first used.
Prefer  for loops to  while loops.
Item 46: Prefer for-each loops to traditional for loops
Use the for each loops to iterate the arrays.
Exception:

1. you need to remove the elements.
2. you need to change the value of elements.
3. special control for the pace of iteration.

Item 47: Know and use the libraries
Be familiar with the contents of java.lang, java.util, and, to a lesser extent, java.io.
Item 48: Avoid  float and double  if exact answers are required
Use the BigDecimal or int or long instead.
int for number with less than 9 digits and long for 19 digits.
Item 49: Prefer primitive types to boxed primitives
“==” operation to mixture of primitive and boxed primitive compares the reference identity but not value.
Use autoboxing carefully.
Item 50: Avoid strings where other types are more appropriate
Do not use string type in everywhere.
Item 51: Beware the performance of string concatenation
Use append() of StringBuilder instead.
Item 52: Refer to objects by their interfaces
Using interface as parameter type make the program more flexible.
List<Subscriber> subscribers = new Vector<Subscriber>();
List<Subscriber> subscribers = new ArrayList<Subscriber>();
Item 53: Prefer interfaces to reflection
Reflection loses all information of complile-time check.
Reflection is only used at design time.
When using the class unknown at compile time, try to only instantiate them by reflection. Access fields and call methods using interfaces or superclasses.
Item 54: Use native methods judiciously 
Avoid using native code unless you really need it.
Item 55: Optimize judiciously
Weshould  forget about small efficiencies, say about 97% of the time: prema-ture optimization is the root of all evil.  –Donald E. Knuth.
Write good programs but not fast programs.
Item 56: Adhere to generally accepted naming conventions
Generally, follow The Java Language Specification as conventions.
Package      com.google.inject, org.joda.time.format
Class or Interface     Timer, FutureTask, LinkedHashMap, HttpServlet
Method or Field    remove, ensureCapacity, getCrc
Constant Field      MIN_VALUE, NEGATIVE_INFINITY
Local Variable      i, xref, houseNumber
Type Parameter    T, E, K, V, X, T1, T2
Item 57: Use exceptions only for exceptional conditions
Do not use the exception for control flow, exception is designed for exceptional condition.
Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors
Checked exception is used in recoverable case. For that, it need to provide information or methods to help the caller to recover.
Item 59: Avoid unnecessary use of checked exceptions
Avoid using the checked exception unless:

• the exception can not avoided by proper use of API.
• Handling exception brings benefits.

Item 60: Favor the use of standard exceptions
Some commonly used exceptions:
IllegalArgumentException: Non-null parameter value is inappropriate
IllegalStateException: Object state is inappropriate for method invocation
NullPointerException: Parameter value is null where prohibited
IndexOutOfBoundsException: Index parameter value is out of range
ConcurrentModificationException: Concurrent modification of an object has been detected where it is prohibited
UnsupportedOperationException: Object does not support method
Item 61: Throw exceptions appropriate to the abstraction
If it is impossible to prevent the occurring of exception in lower level, propagate it to higher level by catching and rethrowing.
Try to log the exception information if detailed information is needed.
Item 62: Document all exceptions thrown by each method
Document the exceptions by Javadoc @throws tag. Do not “throws” unchecked exceptions.
Item 63: Include failure-capture information in detail messages
Include failure-capture information in checked exceptions. Those information is useful in recovering from failure.
Item 64: Strive for failure atomicity
Any generated exception should leave the object in the same state it was in prior to the method invocation.
Example:

1 2 3 4 5 6 7

public Object pop() { if (size == 0) throw new EmptyStackException(); Object result = elements[--size]; elements[size] = null; // Eliminate obsolete reference return result; }

Do not try to maintain the failure atomicity when throwing errors.
Item 65: Don’t ignore exceptions
Do not use empty catch block to ignore the exception. Throw it outward at least if you do not know how to handle it.
Item 66: Synchronize access to shared mutable data
Synchronization includes two parts: mutual exclusion and visibility. Without synchronization, one thread’s changes might not be visible to other threads.
Do not use  Thread.stop as it is depreciated.
Synchronization has no effect unless both read and write operations are synchronized.
Volatile and Atomic types should be carefully used.
Item 67: Avoid excessive synchronization
Do not call alien methods in synchronized block. Doing this is uncontrollable and may cause exceptions and deadlock.
Use concurrent containers like CopyOnWriteArrayList to separate the data writing and reading. This is particularly useful to the situation in which writing data is happened occasionally.
In a multicore world, the real cost of excessive synchronization is not the CPU time spent obtaining locks; it is the lost opportunities for parallelism and the delays imposed by the need to ensure that every core has a consistent view of memory.
Do not synchronize the class internally unless you have good reason.
Item 68: Prefer executors and tasks to threads
Executor framework separate the task and mechanism of executing. So use executors prior to  Thread.
Using Executors.newFixedThreadPool under heavy loading situations.
Using ScheduledThreadPoolExecutor prior to Timer when multiple timing tasked are required.
Item 68: Prefer executors and tasks to threads
The higher-level utilities in java.util.concurrent fall into three categories:the Executor Framework, concurrent collections; and synchronizers.
Utilities in the concurrent library should be considered first before wait() and notify().
Use  ConcurrentHashMap in preference to  Collections.synchronizedMap  or  Hashtable.
Common synchronizers include CyclicBarrier, CountdownLatch and Semaphore.
Item 70: Document thread safety
The presence of the synchronized modifierin a method declaration is an implementation detail, not a part of its exported API.
To enable safe concurrent use, a class must clearly document what level of thread safety it supports.
levels of thread safety:

• immutable
• unconditionally thread-safe
• conditionally thread-safe
• not thread-safe

Item 71: Use lazy initialization judiciously
Lazy initialization decreases the cost of initializing a class or creating an instance, at the expense of increasing the cost of accessing the lazily initialized field. It may be worthwhile when only part of instances will be initialized in practice.
Use a synchronized accessor to the getfield method to ensure the concurrency.
Use the lazy initialization holder class idiom for static field.

1 2 3 4 5

// Lazy initialization holder class idiom for static fields private static class FieldHolder { static final FieldType field = computeFieldValue(); } static FieldType getField() { return FieldHolder.field; }

Use the double-check idiom for instance field.

1 2 3 4 5 6 7 8 9 10 11 12 13

// Double-check idiom for lazy initialization of instance fields private volatile FieldType field; FieldType getField() { FieldType result = field; if (result == null) { // First check (no locking) synchronized(this) { result = field; if (result == null) // Second check (with locking) field = result = computeFieldValue(); } } return result; }

Item 72: Don’t depend on the thread scheduler
Do not rely on scheduler for correctness of program.
Do not let the thread busy-wait.
Use Thread.sleep(1) instead of Thread.yield() for increasing concurrency.
Item 73: Avoid thread groups
Thread groups are obsolete.
Item 74: Implement  Serializable judiciously
Long term cost of implementing Serializable include:
Decreases the flexi-bility to change a class’s implementation once it has been released.
Increase the likelihood of bug and security holes.
Increase the burden of testing.
Classes designed for inheritance  should rarely implement Serializable, and interfaces should rarely extend it.
Exceptions: Throwable, Component, and HttpServlet, etc.
Item 75: Consider using a custom serialized form
Use the default serialized form only when an object’s phys-ical representation is identical to its logical content.
Disadvantages of inappropriate default serialized form:

• permanently ties the exported API to the  current internal representation.
• consume excessive space.
• consume excessive time (graph traversal).
• stack overflow.

Provide writeObject and readOb-ject methods implementing this serialized form.  The transient modifier indicates that an instance field is to be omitted from a class’s default serialized form.
Before deciding to make a field nontransient, convince yourself that its value is part of the logical state of the object.
Declare an explicit serial version UID in every serializable class you write, to tackle the version problem.
Item 76: Write  readObject methods defensively
Make defensive copy of fields in readObject() method is necessary like in the constructor.
For classes with object reference fields that must remain private, defensively copy each object in such a field.
Check any invariants and throw an  InvalidObjectException if a check fails.
Do not invoke any overridable methods in the constructor or readObject() method.
Item 77: For instance control, prefer enum types to readResolve
The instance control (e.g, Singleton) is violated without readResolve() method after serialization.
All instance fields with object reference types must be declared transient if using the readResolve() to do the instance control.
Instance control through Enum is preferred to the readResolve().
Item 78: Consider serialization proxies instead of serialized instances
Serialization proxy pattern is implemented based on an inner static class with a single constructor.
Use writeReplace() of enclosing class to write a proxy instance instead of the instance of enclosing class.
Use readResolve() method to return a instance of enclosing class at the time of deserialization, since the method in the inner class is able to call the constructor of enclosing class.
Two limitations of the serialization proxy pattern:
It is not compatible with classes that are extendable by their clients (in that time, the enclosing class has not been initialized).
It is not compatible with some classes whose object graphs contain circularities.
Serialization proxy pattern is more secure, but with higher expense.

Source

Notes of “Effective Java” (Chapter 1-6)

Item 1: Consider static factory methods instead of constructors
advantage:

1. Customized meaningful names better than constructors.
2. Associated with class instead of creating new objects.
3. Able to return subtypes.

For the 2nd advantage, static factory methods form the basis of Service provider Framework including service interface, provider interface, provider registration API and service access API.
Item 2: Consider a builder when faced with many constructor parameters
Compare with telescoping constructors and JavaBean Style.
Builder is set as a static inner class. Builder makes the object initialized immutable.

Item 3: Enforce the singleton property with a private constructor or an enum type
Three ways to implement Singleton patter:

• Public field
• Static factory method
• Enum Singleton

Without Enum, readResovle() function needs to be added to avoid creating spurious instances when doing serialization.
Item 4: Enforce noninstantiability with a private constructor
Some utility classes like java.lang.Math or java.util.Arrays are not designed to be instantiated. For preventing them from instantiation and subclassing, make the constructor to be private.
Item 5: Avoid creating unnecessary objects
Creating new object especially heavy objects is expensive. Therefore, reusing object always increases efficiency.
Example: String appending, Boxed primitives.
Item 6: Eliminate obsolete object references
Although Java has garbage collector, memory leak can still happen. GC reclaims the memory by inspecting the references of objects.
Therefore, we need to null out the obsolete object references to release the unused object memory.
Common memory leak scenarios: Objects constructed inside classes, Cache, Callbacks.
Notice the Weak references and weakHashmap.
Item 7: Avoid finalizers
In summary, don’t use finalizers except as a safety net or to terminate noncritical native resources. In those rare instances where you do use a finalizer, remember to invoke super.finalize.
Explicit termination inside a “try finally” is preferable and reliable.
Item 8: Obey the general contract when overriding equals
Conditions do not need overriding equals():

1. Instances are distinguished by reference.
2. Equals() defined in superclass works.
3. You do not care the equals() function.

Contract when overriding equals():
Reflexive, Symmetric, Transitive, Consistent.
There is no perfect way to override equals() between the subclasses with additional value components and superclasses.
Notice the @Override annotation.
Item 9: Always override hashCode when you override equals
Principle: equal objects according the equals() function must produce the same hashcode.
General recipe for hashCode():
result = 31 * result + c;

• boolean: (f?1:0).
•  byte, char, short, or int: (int) f
• long: (int) (f ^ (f >>> 32))
• float: Float.floatToIntBits(f)
• double: Double.doubleToLongBits(f)
•  null: 0

Note we could lazily initialize the hashCode value.
Item 10: Always override toString
Faciliate the class client user by giving useful information in string.
Item 11: Override clone judiciously
Once one class implements the Cloneable interface and overrides the clone() method, invoking super.clone() will return a field-to-field copy of this class object in which the method is called. If a class contains only primitive fields or references to immutable objects, then it is usually the case that no fields in the object returned by super.clone need to be modified. Otherwise, deep copy is needed.
Be careful to use clone except for arrays. Usually it is better to use copy constructor and copy factory method.

• public Yum(Yum yum);
• public static Yum newInstance(Yum yum);

Item 12: Consider implementing Comparable

1 2 3

public interface Comparable<T> { int compareTo(T t); }

Classes that depend on comparison include the sorted collections TreeSet and TreeMap, and the utility classes Collections and Arrays, which contain searching and sorting algorithms. General interfaces like Set, Map, and Collection depend on equals() method.
Principle:
If the most significant fields are equal, go on to compare the next-most-significant fields, and so on. If all fields are equal, the objects are equal; return zero.
Item 13: Minimize the accessibility of classes and members
The rule of thumb is simple: make each class or member as inaccessible as possible.
Exported API: public, protected.
If a method overrides a superclass method, it is not permitted to have a lower access level in the subclass than it does in the superclass. This is necessary to ensure that an instance of the subclass is usable anywhere that an instance of the superclass is usable.  A special case of this rule is that if a class implements an interface, all of the class methods that are also present in the interface must be declared public. This is so because all members of an interface are implicitly public.

• Instance fields should never be public
• Classes with public mutable fields are not thread-safe
• Public static final fields should be only used for constants

Item 14: In public classes, use accessor methods, not public fields
Class is package-private or is a private nested class, there is nothing inherently wrong with exposing its data fields.
Item 15: Minimize mutability

1. Make the immutable class to be final.
2. Immutable objects are inherently thread-safe; they require no synchroni-zation.
3. Use companion class such as StringBuilder replacing String for performance.
4. Static factory is a good way for immutable class.
5. Classes should be immutable unless there’s a very good reason to make them mutable.
6. Make every field final unless there is a compelling reason to make it nonfinal.
7. Don’t provide a public initialization method separate from the constructor or static factory unless there is a compelling reason to do so.

Item 16: Favor composition over inheritance
For most cases, composition is better than inheritance.
The keyword “super” is for calling overrided methods or constructors in superclass. The invocation in super.method() still calls the override methods but not overriden methods.
Item 17: Design and document for inheritance or else prohibit it

• The class must document or simply prohibit its  self-use of overridable methods.
• Constructors must not invoke overridable methods.
• Neither clone() nor readObject() may invoke an overridable method, directly or indirectly, as they behave like constructors.
• Prohibit subclassing in classes that are not designed and documented to be safely subclassed by “final” or making the constructor “private”.

Item 18: Prefer interfaces to abstract classes
Interface is generally the better way to define a type that permits multiple implementations.
Abstract class and Interface can be combined to generate skeletal implementation, such as AbstractCollection, AbstractSet, AbstractList.
Item 19: Use interfaces only to define types
Interfaces should only used to define type, representing some classes in hierarchy.
Enum and Utility class are more appropriate for defining constants.
Item 20: Prefer class hierarchies to tagged classes
Tagged classes are cluttered with tag fields, and switch statements, messing the encapsulation and  being prone to run-time errors.
Tagged class should be abandoned and replaced by abstract classes.
Item 21: Use function objects to represent strategies
Features like function pointers, delegates, lambda expressions call functions in functions.
Strategy pattern is built on these features typically on function pointers.
Function pointers is not supported in java. However, it can be emulated by a concrete class with only one method, as a “concrete strategy class”.

• Strategy ==> Interface
• Concrete strategy ==> Concrete class implementing the interface

Usually the concrete class is used as anonymous class. For class used repeatedly, singleton pattern is applied to the concrete class with one static and final instance.
Item 22: Favor static member classes over nonstatic
Four kinds of nested classes: static member classes, nonstatic member classes, anonymous classes, and local classes.
It is impossible to create an instance of a nonstatic member class without an enclosing instance.
Declare a member class that does not require access to an enclosing instance, always make it to be static.
Three common uses of anonymous classes:

1. function objects
2. process objects, such asRunnable, Thread
3. static factory methods

Item 23: Don’t use raw types in new code

• Do not use raw type to define variable, as the compiler will not check the type of parameters and it loses the type safety and may generate run-time error.
• Generics like List<Object> can contain any arbitrary types but still with type safety.
• Unbounded wildcard types like List<?> is capable to hold one of any type of element with type safety.
• Generic type information is erased at runtime

Item 24: Eliminate unchecked warnings
Try to eliminate the unchecked warning, including:

• unchecked cast warnings
• unchecked method invocation warnings
• unchecked generic array creation warnings
• unchecked conversion warnings

Suppress the warning with an @SuppressWarnings(“unchecked”) annotation in narrowest scope if you are sure about the type safety.
Item 25: Prefer lists to arrays
Arrays are covariant and reifiable. Generics are invariant and erased in run-time.
Arrays provide runtime type safety but not compile-time type safety and vice versa for generics.

1 2 3

// Fails at runtime! Object[] objectArray = new Long[1]; objectArray[0] = "I don't fit in"; // Throws ArrayStoreException

1 2 3

// Won't compile! List<Object> ol = new ArrayList<Long>(); // Incompatible types ol.add("I don't fit in");

Generics enforce their type constraints only at compile time and discard (or erase) their element type information at runtime.
it is illegal to create an array of a generic type such as “new List<String>[]” and “new List<E>[]“.
Non-reifiable type is one whose runtime representation contains less information than its compile-time representa-tion.
Casts to arrays of non-reifiable types should be used only under special circumstances. A better solution is to use list.
Item 26: Favor generic types
Generics are safer. Suppress the warning when casting.

1 2 3 4

@SuppressWarnings("unchecked") public Stack() { elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY]; }

Item 27: Favor generic methods
Generic singleton factory:

1 2 3 4 5 6 7 8 9 10 11 12

// Generic singleton factory pattern private static UnaryFunction<Object> IDENTITY_FUNCTION = new UnaryFunction<Object>() { public Object apply(Object arg) { return arg; } }; // IDENTITY_FUNCTION is stateless and its type parameter is // unbounded so it's safe to share one instance across all types. @SuppressWarnings("unchecked") public static <T> UnaryFunction<T> identityFunction() { return (UnaryFunction<T>) IDENTITY_FUNCTION; }

Recursive type bound is usually used for Comparable<T>.

1 2 3 4 5

public interface Comparable<T>; { int compareTo(T o); } // Using a recursive type bound to express mutual comparability public static <T extends Comparable<T>> T max(List<T> list) {...}

Item 28: Use bounded wildcards to increase API flexibility
Producer-extends, consumer-super(PECS)

1 2 3 4 5 6 7 8 9 10

// Wildcard type for parameter that serves as an E producer public void pushAll(Iterable<? extends E> src) { for (E e : src) push(e); } // Wildcard type for parameter that serves as an E consumer public void popAll(Collection<? super E> dst) { while (!isEmpty()) dst.add(pop()); }

Do not use wildcard types as return types. Rather than providing additional flexibility for your users, it would force them to use wildcard types in client code.
Always use Comparable<? super T> in preference to Comparable<T>, since the type may implements the Comparable interface as an subinterface.
If a type parameter appears only once in a method declaration, replace it with a wildcard.
Can’t put any value except null into a List<?>, which means List of some particular type.
Item 29: Consider typesafe heterogeneous containers
Place the type parameter on the key rather than the container to enable the container to include different types.

1 2 3 4 5 6 7 8 9 10 11 12 13

// Typesafe heterogeneous container pattern - implementation public class Favorites { private Map<Class<?>, Object> favorites = new HashMap<Class<?>, Object>(); public <T> void putFavorite(Class<T> type, T instance) { if (type == null) throw new NullPointerException("Type is null"); favorites.put(type, instance); } public <T> T getFavorite(Class<T> type) { return type.cast(favorites.get(type)); } }

Item 30: Use enums instead of int constants
Java’s enum types are full-fledged classes.
Enums provide high-quality implementations of all the Object methods, Comparable and Serializable.
Enums can also add methods or fields.

1 2 3 4 5 6 7 8

// Enum type with constant-specific method implementations public enum Operation { PLUS { double apply(double x, double y){return x + y;} }, MINUS { double apply(double x, double y){return x - y;} }, TIMES { double apply(double x, double y){return x * y;} }, DIVIDE { double apply(double x, double y){return x / y;} }; abstract double apply(double x, double y); }

ValueOf(String) method can translate a constant’s name into the constant itself.
Consider the strategy enum pattern if multiple enum constants share common behaviors.
Item 31: Use instance fields instead of ordinals
Avoid using ordinal() method of enum.

1 2 3 4 5 6

// Abuse of ordinal to derive an associated value - DON'T DO THIS public enum Ensemble { SOLO, DUET, TRIO, QUARTET, QUINTET, SEXTET, SEPTET, OCTET, NONET, DECTET; public int numberOfMusicians() { return ordinal() + 1; } }

Item 32: Use EnumSet instead of bit fields
Use general Set interface for input type.

1 2 3 4 5 6

// EnumSet - a modern replacement for bit fields public class Text { public enum Style { BOLD, ITALIC, UNDERLINE, STRIKETHROUGH } // Any Set could be passed in, but EnumSet is clearly best public void applyStyles(Set<Style> styles) { ... } }

Item 33: Use EnumMap instead of ordinal indexing
It is better to use EnumMap to catalog relationship related with Enum type.

1 2 3 4 5 6 7 8

// Using an EnumMap to associate data with an enum Map<Herb.Type, Set<Herb>> herbsByType = new EnumMap<Herb.Type, Set<Herb>>(Herb.Type.class); for (Herb.Type t : Herb.Type.values()) herbsByType.put(t, new HashSet<Herb>()); for (Herb h : garden) herbsByType.get(h.type).add(h); System.out.println(herbsByType);

Item 34: Emulate extensible enums with interfaces
In general, extending enums is a bad idea. If you really want to do that, define an interface for expected behaviors.
Item 35: Prefer annotations to naming patterns
Annotations do not directly affect program semantics, but they do affect the way programs are treated by tools and libraries, which can in turn affect the semantics of the running program. Annotations can be read from source files, class files, or reflectively at run time.
Annotations complement javadoc tags. In general, if the markup is intended to affect or produce documentation, it should probably be a javadoc tag; otherwise, it should be an annotation.
Item 36: Consistently use the Override annotation
Use @Override annotation except for the abstract methods or methods of interfaces.

Source

Javapocalypse video

Extend Thread vs implement Runnable

There are two ways to create your own thread type: subclass java.lang.Thread class, or implementing java.lang.Runnable and pass it to Thread constructor or java.util.concurrent.ThreadFactory. What is the difference, and which one is better?

1. The practical reason is, a Java class can have only one superclass. So if your thread class extends java.lang.Thread, it cannot inherit from any other classes. This limits how you can reuse your application logic.
2. From a design point of view, there should be a clean separation between how a task is identified and defined, between how it is executed. The former is the responsibility of a Runnalbe impl, and the latter is job of the Thread class.
3. A Runnable instance can be passed to other libraries that accept task submission, e.g., java.util.concurrent.Executors. A Thread subclass inherits all the overhead of thread management and is hard to reuse.
4. Their instances also have different lifecycle. Once a thread is started and completed its work, it's subject to garbage collection. An instance of Runnalbe task can be resubmitted or retried multiple times, though usually new tasks are instantiated for each submission to ease state management.

O(n) for operations on Java collections

Collection Interfaces - Java Collection Diagrams

And when we include maps:

Avoid memory leaks using Weak&Soft references

Some Java developers believe that there is no such a thing as memory leak in Java (thanks to the fabulous automatic Garbage Collection concept)

Some others had met the OutOfMemoryError and understood that the JVM has encountered some memory issue but they are not sure if it’s all about the code or maybe even an OS issue…

The OutOfMemoryError API docs reveals that it “Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector. “

As we know, the JVM has a parameter that represents the maximum heap size(-Xmx), hence we can defiantly try to increase the heap size. yet some code can generate new instances all the time, if those instances are accessible(being referenced by the main program – in a recursive manner) for the entire program life span, then the GC won’t reclaim those instances. hence the heap will keep increasing and eventually a OutOfMemoryError will be thrown <- we call that memory leak.

Our job as Java developers is to release references (that are accessible by the main program) that we won’t use in the future. by doing that we are making sure that the GC will reclaim those instances (free the memory that those instances occupying in the heap).

In some cases we reference an instance from 2 different roots. one root represent a fast-retrieval space(e.g. HashMap) and the other manages the real lifespan of that instance. Sometimes we would like to remove the reference of that instance from one root and get the other root(fast retrieval) reference removed automatically.

We wouldn’t want to do it manually due to the fact that we are not C++ developers and we wouldn’t like to manage the memory manually..

Weak references

In order to solve that we can use WeakReference.

Instances that are being referenced by only Weak references will get collected on the next collection! (Weakly reachable), in other words those references don’t protect their value from the garbage collector.

Hence if we would like to manage the life span of an instance by one reference only, we will use the WeakReference object to create all the other references.

( usage: WeakReference wr = new WeakReference(someObject);)

In some apps we would like to add all our existing references to some static list, those references should not be strong, otherwise we would have to clean those references manually, we would add those references to the list using this code.

public static void addWeakReference(Object o){
   refList.add(new WeakReference(o));
}

since most of the WeakReferences use cases needs a Map data structure, there is an implementation of Map that add a WeakReference automatically for you – WeakHashMap

Soft References

I saw few implementations of Cache using weak references (e.g. the cache is just a WeakHashMap => the GC is cleaning old objects in the cahce), without WeakReferences naive cache can easily cause memory leaks and therefor weak references might be a solution for that.

The main problem is that the GC will clean the cached-object probably and most-likely faster then you need.

Soft references solve that, those references are exactly like weak references, yet the GC won’t claim them as fast. we can be sure that the JVM won’t throw an OutOfMemory before it will claim all the soft and weak references!

using a soft references in order to cache considered the naive generic cache solution. (poor’s men cache)

( usage:SoftReference sr = new SoftReference(someObject);)

Java Forever - Official Video

One java - 2 compilers (Javac and JIT)

It seems like that for students there is a lot of confusion regarding how Java/The JVM works because there are TWO compilers involve, so when someone mentions a compiler or the Just In Time compiler some of them would imagine it’s the same one, the Java Compiler..

So how does it really works?

It’s simple..

1) You write Java code (file.java) which compiles to “bytecode“, this is done using the ‘javac” the 1st compiler.

It’s well known fact that Java can be written once get compiled and run anywhere (on any platform) which mean that different types of JVM can get installed over any type of platform and read the same good old byte code

2) Upon execution of a Java program (the class file or Jar file that consists of some classes and other resources) the JVM should somehow execute the program and somehow translate it to the specific platform machine code.

In the first versions of Java, the JVM was a “stupid” interprater that executes byte-code line by line….that was extremely slow…people got mad, there were a lot of “lame-java, awesome c” talks…and the JVM guys got irratated and reinvented the JVM.

the “new” JVM initially was available as an add-on for Java 1.2 later it became the default Sun JVM (1.3+).

So what did they do? they added a second compiler.. Just In Time compiler(aka JIT)..

Instead of interpreting line by line, the JIT compiler compiles the byte-code to machine-code right after the execution..

Moreover, the JVM is getting smarter upon every release, it “knows” when it should interpat the code line-by-line and what parts of the code should get compiled beforehand (still on runtime).

It does that by taking real-usage statistics, and a long-list of super-awesome heuristics..

The JVM can get configured by the user in order to disable/enable some of those heuristics..

To summarize, In order to execute java code, you use two different compilers, the first one(javac) is generic and compiles java to bytecode, the second(jit) is platform-dependent and compiles some portions of the bytecode to machine-code in runtime!

Optimizing and Speeding up the code in Java

Finalizers: object that overwrites the finalize() method (“Called by the garbage collector on an object when garbage collection determines that there are no more references to the object.”) is slower!(for both allocation and collection) if it’s not a must, do clean ups in other ways ( e.g. in JDBC close the connection using the try-catch-finally block instead)

New is expensive: creating new heavy object() on the heap is expensive!, it’s recommended to recycle old objects (by changing their fields) or use the flyweight design pattern.

Strings : (1) Strings are immutable which mean that upon usage of the + operator between 2 strings the JVM will generate a new String(s1+s2) on the heap (expensive as I just mentioned), in order to avoid that, it’s recommended to use the StringBuffer.(Update) since JDK 1.5 was introduced  StringBuilder is a better option than Stringbuffer in a single-threaded environment.

(2) Don’t convert your strings to lower case in order to compare them, use String.equalIgnoreCase() instead.

(3) String.startswith() is more expensive than String.charat(0) for the first character.

Inline method: inline is a compiler feature, when you call a method from anywhere in your code, the compiler copies the content of the inline method and replace the line that calls the method with it.

Obviously,It saves runtime time: (1) there is no need to call a method (2) no dynamic dispatch.

In some languages you can annotate a method to be inline, yet in Java it’s impossible, it’s the compiler decision.

the compiler will consider inline a method if the method is private.

My recommendation is to search in your code for methods that are heavily used(mostly in loops) and annotate those method as private if possible.

Don’t invent the wheel: the java api is smart and sophisticated and in some cases use native implementation, code that you probably can’t compete with. unless you know what you are doing (performance wise) don’t rewrite methods that already exists in the java API. e.g. benchmarks showed that coping and array using a for loop is at least n/4 times slower than using System.arraycopy()

Reflection: reflection became much faster for those of you who use the most recent JVMs, yet using reflection is most certainly slower than not using it. which mean that you better avoid reflection if there is no need.

Synchronization: Some data structures auto-support concurrency, in case of a single thread application don’t use those to avoid overhead e.g. use ArrayList instead of a Vector

Multithreads: in case of a multi processor use threads, it will defiantly speed up your code, if you are not a thread expert some compilers know how to restructure your code to thread automatically for you. you can always read a java threads tutorial as well

Get familiar with the standard data structures:   e.g. if you need a dast for puting and retriving objects use HashMap and not an ArrayList. (O(1))

Add an id field, for faster equals(): object that contains many fields are hard to compare ( equals() wise), to avoid that add an id(unique) field to your object and overwrite the equals() method to compare ids only.

Be careful, In case  your code already works, optimizing it is a sure way to create new bugs and make your code less maintainable!

it’s highly recommended to time your method before and after an optimization.

101 reasos why java is better than .net

I was once reading the interesting article and so I decided to share on this blog:
link

Divide by Zero in case of Java

One of the good interview questions I found was related to divide by zero.
Lets take the case:

What will be the output of this code snippet?

public class NaN {
 
    public static void main(String[] args) {
        double d = 2.0 / 0.0;
        System.out.println(d);
    }
}

What's the answer: The code will not compile or will it throw a DivideByZero error? Both are wrong. The code compiles fine and the output is,

Infinity

Let's check another code snippet,

public class NaN {
 
    public static void main(String[] args) {
        double d = 0.0 / 0.0;
        System.out.println(d);
    }
}

The output in this case is,

NaN

Hello World in Ruby using Netbeans

After getting a decent knowledge of what Ruby is and the useful resources that are available, lets get into action by creating our first hello world program.

Ruby and Ruby on Rails development becomes amazingly easy using Netbeans IDE where you can perform almost all the tasks in one single IDE. Download and install the Netbeans-Ruby version. You should be having JDK installed in your box, thats pretty much the pre-requisite for Netbeans to install.

OR you can simply download the complete version of netbeans and install ruby plugins.

Download the ruby from here. Extract it to some location, Say C:\\ruby
Now create new project.
Launch Netbeans go to File --> New Project. A new project wizard should come up. Select Ruby Application i.e. C:ruby\bin., click Next and click Finish. Thats it!!!!
You dont even have to type a Hello World. The new project template does it for you! So sweet isnt it? Now, click on the big green Run button and the console should print out Hello World without a hitch.

Now just run the program :)

installing RadRails on Eclipse

I could not find a proper answer when i wanted to install RadRails on eclipse . This is how it is done , .... in the Eclipse menu go to
Help-->Software Updates --> Find and Install....
then in the pop - up window which appears ,..
Search for new features to install
and then click next and then u will have to add 2 new remote sites, .. the details for the sites are the ones which were very difficult to obtain , they are
site 1 :
Name :RadRails
URL : http://radrails.sourceforge.net/update
site 2 :
Name :RDT
URL : http://updatesite.rubypeople.org/release
then click on finish , u are almost done with the installation , u have to just follow the instructions from here on to finish the installation .

This entry was posted on Friday, May 16, 2008 at 8:37 PM and is filed under eclipse, linux, ruby . You can follow any responses to this entry through the comments feed .

Making collections final

Once we write final

ArrayList list = new ArrayList();

We can add, delete objects from this list, but I can not

list = new ArrayList() or list = list1.

So declaring the list final means that you cannot reassign the list variable to another object.

There are two situations in which this can be useful.

1. You want to make sure that no-one reassigns your list variable once it has received its value. This can reduce complexity and helps in understanding the semantics of your class/method. In this case you are usually better off by using good naming conventions and reducing method length (the class/method is already too complex to be easily understood).
2. When using inner classes you need to declare variables as final in an enclosing scope so that you can access them in the inner class. This way, Java can copy your final variable into the inner class object (it will never change its value) and the inner class object does not need to worry what happens to the outer class object while the inner class object is alive and needs to access the value of that variable.

Difference between Proxy, Decorator, Adaptor, and Bridge Patterns ?

Proxy, Decorator, Adapter, and Bridge are all variations on "wrapping" a class. But their uses are different.

• Proxy could be used when you want to lazy-instantiate an object, or hide the fact that you're calling a remote service, or control access to the object.
  See proxy pattern with details.
• Decorator is also called "Smart Proxy." This is used when you want to add functionality to an object, but not by extending that object's type. This allows you to do so at runtime.
• Adapter / Wrapper is used when you have an abstract interface, and you want to map that interface to another object which has similar functional role, but a different interface.
  In particular Decorator looks very close to Adapter but still there is basic difference:
  

  	Adapter / Wrapper	Decorator
  Composes "origin" class	True	True
  Modifies original interface	True	False
  Modifies behavior of interface	False	True
  Proxies method calls	True	True

   
  See Adapter pattern and Decorator Pattern with examples.
• Bridge is very similar to Adapter, but we call it Bridge when you define both the abstract interface and the underlying implementation. I.e. you're not adapting to some legacy or third-party code, you're the designer of all the code but you need to be able to swap out different implementations.
  See bridge pattern with example.
• Facade is a higher-level (read: simpler) interface to a subsystem of one or more classes. Think of Facade as a sort of container for other objects, as opposed to simply a wrapper. So you don't have to worry about so many things, just call the facade to do all the stuff.
  See Facade pattern with example.

Interface And Abstraction – Spiritual Explanation

“What is the difference between interface and abstract class?”, a typical interview question . Answer is so obvious, and we can list at least 3 differences. Here is an attempt to correlate Object Oriented world with spiritual world, and explain abstraction and interface.

“Soul is an abstract notion realized by concrete living being”. So as per OO world, if you got “Soul” as abstract class, you got to have a concrete class “Life”. Soul can not operate without Life.

Just like I said object is an entity with an objective to live, abstract class can live through concrete class. Inheritance is the only mechanism for an abstract class to live. Spiritually, Soul operates through life. Life is an object with a process thread running in it.

In Spiritual world, it is said that “Soul carries the karma (good or bad actions) from previous life, which has influences in the new life”. If you consider this statement, karma is the action log recorded into the abstract class.

Body is an interface to life (and hence interface to Soul) and real world. so IBody can be implemented by body of human, bird or any living creature. Once the objective is complete in this real world, destructor is called on life object. However actions are kept recorded (like log files) in the abstract class through out this new life.

In every new life actions recorded in abstract class is not revealed, as it is private declaration . Only the ultimate object builder (God)  has access to it. Object builder reads this private variable, and makes the decision of choosing a new interface for Soul. Dispose method is programmed to be called in a timer function. When timer event fires, dispose is called, and the Life object is disposed terminating the process thread.

After thread is terminated and Life is disposed, Object builder reads the record log from Soul class. Based on the karma recorded in the log, a new object with the suitable interface (body) is created, and Life is induced into it with a process thread. And a timer is started in the Life class, which when fires Thread Abort is called.

Shallow Copy and Deep Copy

There are two ways to make a copy of an object called shallow copy and deep copy.
Here is what they mean:

Shallow Copy
Shallow copy is a bit-wise copy of an object. A new object is created that has an exact copy of the values in the original object. If any of the fields of the object are references to other objects, just the references are copied. Thus, if the object you are copying contains references to yet other objects, a shallow copy refers to the same subobjects.

Deep Copy
Deep copy is a complete duplicate copy of an object. If an object has references to other objects, complete new copies of those objects are also made. A deep copy generates a copy not only of the primitive values of the original object, but copies of all subobjects as well, all the way to the bottom. If you need a true, complete copy of the original object, then you will need to implement a full deep copy for the object.

Shallow Copy

Deep Copy

You may like : 
Design patterns using shallow copy and deep copy - Prototype pattern
Shallow and deep copy using clone

MVC Pattern Basics

Definition
The Model-View-Controller (MVC) architectural pattern is used in software engineering to allow for the separation of three common features in GUI applications:

• the data access (typically via a database)
• the business logic (how the data will be used)
• user interaction (how the data and actions will be visually presented)

MVC pattern differenciates all the 3 aspects of application in 3 difft tiers.

Modal
It incorporates following point

•  Holds the business logic of the application.
•  holds data sent between different. tiers like JSP to servlet and handler classes.
• One of the goals of the model is to give a presentation which does not directly refer to any specific DBMS. 

View

• This represents the visible user interface, so handles presentation tier of the application.
• it knows enough about the data to create a coherent presentation, but does not actually do the work of presenting the data. Instead, it provides the ability to manipulate data outside the View through event handlers defined within. 
• handles presentation logic, client side validation.
• e.g. HTML, JSP

Controller

• handles the flow of the application
• Joins the Model with the View and is the heart of the business logic.
• It is the source of activity when an event occurs and defines the event handling actions which access data (from the Model) and are presented to the user (in the View).
• e.g. Servlets, Action Class in Struts, ActionServlet is using struts-config.xml as front controller to handle each request and redirect it to appropriate destination.

Advantages

•  Increases modularity of the application.
•  Increases Maintainability of the application, i.e.  the data presentation can be changed without any notion of how the data is obtained and conversely, the data access can be changed without any knowledge of how it is to be presented. 

Example
to be added soon

Feelings today