Synchronized & Unsynchronized Objects

Synchronized	Unsynchronized
StringBuffer	StringBuilder
Vector	ArrayList
Hashtable	HashMap

Setting the CLASSPATH Sys Var

To display the current CLASSPATH variable, use these commands in Windows and Unix (Bourne shell):

In Windows:   C:\> set CLASSPATH
In Unix:      % echo $CLASSPATH

To delete the current contents of the CLASSPATH variable, use these commands:

In Windows:   C:\> set CLASSPATH=
In Unix:      % unset CLASSPATH; export CLASSPATH

To set the CLASSPATH variable, use these commands (for example):

In Windows:   C:\> set CLASSPATH=C:\users\george\java\classes
In Unix:      % CLASSPATH=/home/george/java/classes; export CLASSPATH

From: http://java.sun.com/docs/books/tutorial/java/package/managingfiles.html

Declaring Constants

I was contemplating for the best way to declare constants in Java and found that there are several ways to do it. The best article I saw regading this topic is here. It helped me decide clearly as to what I should use plus, one of the comments discussed a very interesting information about inlining constants w/c I will also explain later on this blog.

First, I would like to eradicate suggestions/questions that might come up:

Why not use enums? I am referring here to constants that are not related and may even be of different types so enum is not a good choice.

If these constants are not related, why bother grouping them? This is sometimes necessary because there are constants that belong to the same functionality but are not related to each other. You may also want to group constants shared by different classes, more like global constants. These constants do not belong naturally to a certain class so it needs to be grouped somewhere else.

Why not put constants in the class that they are most related to? Aside from the explanation above, this would also lead to dependencies between classes and the constants will clutter. It's always easier to update just one class or few classes.

So what are the options now?

Interface for Constants
ADV:
- cleaner/shorter code because you can define constants without the public static final keywords since they are implicitly public static final
- a class implementing this can refer to the constants without a qualifying class name
DISADV:
- this is not what interface is designed for. Interface is supposed to specify a contract for its services, not to handle data.
- using constant without a qualifying class name can make code more difficult to understand and maintain
- interfaces promotes constants to the API of the class which means that if MyClass implements MyConstantInterface, you can use MyClass.SAMPLE_CONSTANT instead of MyConstantInterface.SAMPLE_CONSTANT. This breaks inheritance and your Javadoc will be full of repeating constants.

Class for Constants with private constructor
ADV:
- cannot be instantiated and cannot be subclassed like interfaces
- the use of qualifying name can add to the readability of the code
DISADV:
- long name, constants are referred using static references like MyConstantClass.SAMPLE_CONSTANT

static import
ADV:
- allow referring to constants without a qualifying class name
DISADV:
- can make code more difficult to understand and maintain

MY CONCLUSION:
You may choose one over another depending on what you need or what is more convenient for you, but for me the best approach is to use class with private constructor. This will avoid all the disadvantages of using an interface. If you still want to use interfaces because of the shorter name reference for constants, you must use static import of a constant class instead. However, this must be taken with precaution. Use it only if you need frequent access of constants from one or very few classes only. Otherwise, readers of your code may get confused as to where a constant comes from.

Now, is there anything else that can do better? Apparently, according to Kevin Riff, there is. When a field is (1)of type primitive or String, (2)declared final, and (3)was initialized upon declaration, it is called "compile-time constant" and it is in-lined in the consumer classes. This means that all reference of this constant is replaced with its actual value at compile time. So if you change the value of a constant, you must recompile not only the containing class but all its consumer classes in order to update the value of the constant.

What is the solution for this? Using a properties file could be considered but if you really need to hard-code your constants in a Java file, you must prevent your constants to be in-line like this,

public class MyLibrary { 
  public static final String VERSION;  // blank final
  static {
    VERSION = "1.0";  // initialized separately
  }
}

The code would seem odd so don't forget to add comments explaining what's going on.

Personally, I might not apply this design because it makes the code look odd and somehow ugly. I would rather recompile all affected classes. It happens to almost any class anyway that when you make a change on it, there will be some affected classes that must be recompiled too.

Java Generics

• introduced in J2SE 5.0
  
• adds robustness/stability on code by making more bugs detectable at compile time
  
• normal way can cause runtime ClassCastException
  

  public class Box {
      private Object object;
      public void add(Object object) {
          this.object = object;
      }
      public Object get() {
          return object;
      }
  }
      Box integerBox = new Box();
      integerBox.add("10"); // note how the type is now String
      Integer someInteger = (Integer)integerBox.get();



• sample generic version with type variable T
  

  public class Box {
  private T t; // T stands for "Type"      
  public void add(T t) {
      this.t = t;
  }
  public T get() {
      return t;
  }
  }
      Box integerBox = new Box();
      integerBox.add(new Integer(10));
      Integer someInteger = integerBox.get(); // no cast!



• generic method/constructor
  

  public static <U> void fillBoxes(U u, List<Box<U>> boxes) {
  for (Box<U> box : boxes) {
      box.add(u);
  }
  }
  Crayon red = ...;
  List<Box<Crayon>> crayonBoxes = ...;
  // normal way
  Box.<Crayon>fillBoxes(red, crayonBoxes);
  // with type inference
  Box.fillBoxes(red, crayonBoxes); // compiler infers that U is Crayon



• Bounded Parameter types -> when variables are restricted to certain types, upper bound only
  

  <U extends Number & MyInterface> // uses extend for both classes & interfaces

• Unknown type/wilcard bounds -> represented by wildcard character "?"
  
  3 different flavors of wildcards:
  • " ? " - the unbounded wildcard. It stands for the family of all types.
  • " ? extends Type " - a wildcard with an upper bound. It stands for the family of all types that are subtypes of Type , type Type being included.
  • " ? super Type " - a wildcard with a lower bound. It stands for the family of all types that are supertypes of Type , type Type being included.

  // Box<Integer> and Box<Double> are not subtypes of Box<Number>
  Box<Number> box = new Box<Integer>(); // compile-time error
  
  // Box<Integer> and Box<Double> are subtypes of Box<? extends Number>
  Box<? extends Number> box = new Box<Integer>(); // ok
  
  Integer i = new Integer(1);
  Number n = i;
  // compile-time error
  // Integer is not '? extends Number'
  // we are not sure that the instance type of Box is Integer, so we cannot add i
  box.add(i); 
  
  // compile-time error
  // Number is not '? extends Number'
  // we are sure that the type of Box extends a Number but we are not sure of the 
  //     instance type of n, so we cannot add n
  // what if runtime type of Box is Box<Double> but n is Integer
  box.add(n)
  
  // compile-time error
  // we are not sure that the type of Box is an Integer
  Integer i2 = box.get();
  
  // we are sure that the type of Box is always extends a Number
  Number n2 = box.get(); // ok
  
  // sample using upperbound & lowerbound wildcards
  public class Collections {
  public static <T> void copy
  ( List<? super T> dest, List<? extends T> src) {  // bounded wildcard parameterized types
     for (int i=0; i<src.size(); i++)
       dest.set(i,src.get(i));
  }
  }



• Type Erasure -> when generic types are instantiated, all generic information are removed leaving only the raw type. Box becomes Box only.
  

  public class MyClass {
      public static void myMethod(Object item) {
          if (item instanceof E) {  //Compiler error
              ...
          }
          E item2 = new E();   //Compiler error
          E[] iArray = new E[10]; //Compiler error
          E obj = (E)new Object(); //Unchecked cast warning
      }
  }

Sources:
http://java.sun.com/docs/books/tutorial/java/generics/index.html
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html

To Study:

-SSL, certificates, keystore, keytool
-html
-jsp
-jsp el(expression lang)
-extjs
-dwr
-tld (tags)

-j2ee
-java
-servlets

-struts
-spring

-drools

-jdbc
-ibatis
-db2
-sql

-ibml
-properties file (adv. of constants in java file)
-logging, log4j

-servers, tomcat
-deployment (war, jar, ear)
-eclipse
-cvs/clearcase/svn
-maven

TODO:
-check ResourceBundle if there's a properties file

Java Inheritance

• Variables
  
  Kinds of variables base on scope: local, instance, class
  
  Hiding/Shadowing Variables
  - redeclaring a variable that’s already been declared somewhere else. The closest scope is used when you refer it through simple name.
  
  1) local var hides instance var
  - use this to access the instance var
  
  2) instance var hides inherited var
  - use super.name or cast the object to its super class, with the syntax ((Superclass)object).name
  - when the variable is accessed thru the object containing it, the variable used depends on the type the object it was declared with or casted to, not the runtime type of the object.


• Methods
  
  Overloading
  - same name, diff arguments, return type doesn't matter
  
  Overriding
  - same signature (method name + arguments), same return type diff classes
  - instance to instance method only
  
  Hiding
  - static to static only
  - when the method is called thru the object containing it, the method used depends on the type the object it was declared with or casted to, not the runtime type of the object.
  
  Not allowed in methods but allowed in variables/fields:
  - static to non-static or vice versa
  - narrowing visibility
  - different return type (but same signature/name) -> compile error in methods


• Object
  - implicit superclass of all classes
  - must be overridden in objects -> equals(), hashCode(), toString()
  
  clone() method
  -protected|public Object clone() throws CloneNotSupportedException
  aCloneableObject.clone();
  - aCloneableObject must implemenet Cloneable interface
  - default behavior of Object's clone() -> creates an object of the same class as the original object and initializes the new object's member variables. But if a member variable is an external object, say ObjExternal, ObjExternal is not cloned but shared. A change in ObjExternal made by one object will be visible in its clone also.
  
  equals() method
  - uses ==
  - if overridden, u must override hashCode() too. If two objects are equal, their hash code must also be equal.
  

  public boolean equals(Object obj) {
     if (obj instanceof Book)
         return ISBN.equals((Book)obj.getISBN());
     else
         return false;
  }

• Abstract vs Interface
  - http://mindprod.com/jgloss/interfacevsabstract.html
  - when to use one over the other:
  General rule is if you are creating something that provides common functionality to unrelated classes, use an interface. If you are creating something for objects that are closely related in a hierarchy, use an abstract class.

Sample CVS config spec

-main

element * CHECKEDOUT
element * /main/LATEST
load \Acctsvcs

-branch

element * CHECKEDOUT
element * /main/nae_phase1c/LATEST
element * /main/NAE_ROOT_PHASE1C -mkbranch nae_phase1c
element * /main/LATEST -mkbranch nae_phase1c
load \Acctsvcs