SCJP 5.0 Study Notes(2)

Encapsulation, coupling, cohesion

<!---->·    <!---->Good encapsulation promotes loose coupling

<!---->·    <!---->Coupling is not used to evaluate classes within the same inheritance tree

<!---->·    <!---->Encapsulations limits the consequences of change

<!---->·    <!---->Encapsulation allows corrections to a class with minimal impact to users of that class

<!---->·    <!---->Encapsulation (and high cohesion) makes it easier to reuse classes

<!---->·    <!---->Encapsulation results in better testing and higher reliability

<!---->·    <!---->Cohesion refers to the number and diversity of tasks that a single unit is responsible for.  A class with one task has high cohesion an any method not focused on a single task shows low cohesion

<!---->·    <!---->Coupling is how linked and non-independent together two classes are.  Loose coupling helps understand one class without studying the others and minimizes changes in one class when another class is changed.

<!---->·    <!---->For method arguments, passing in specific, user-created objects requires tight coupling, since the two objects involved both need to know something about the object being passed in

 

Collections, equals(), and hashCode()

<!---->·    <!---->In order to sort and array or collection, elements must be mutually comparable (same type) – trying to sort different objects will result in runtime exception

<!---->·    <!---->The more unique the hashcode, the faster the retrieval

<!---->·    <!---->the equals() method for an object must be at least as precise as the hashcode() method (equals() and hashcode() CAN use the exact same algorithm)

<!---->·    <!---->.equals() should return false for an object of a different type (but compiles and runs without exceptions)

<!---->·    <!---->HashSet and LinkedHashSet can have null elements, TreeSet can’t (it has to sort)

<!---->·    <!---->HashMap and LinkedHashMap can have a null key and null values, TreeMap can have null values but NOT null keys, and Hashtable can have neither null keys or null values

<!---->·    <!---->For non-generic TreeSet, putting objects of different types will compile fine, but this will produce a runtime error

<!---->·    <!---->For any generics, trying to add the wrong type will not compile (e.g. trying to add a String when <Integer> was specified>

<!---->·    <!---->When you try to add objects without a “compareTo” method to a Set, code will compile fine but a ClassCastException will be thrown at runtime (trying to cast object to a Comparable)

<!---->·    <!---->It is LEGAL to assign generic type collections to raw type collections, e.g. Vector v = new Vector<Integer>()

<!---->·    <!---->Trying to add an object that does not implement comparable to an sorted collection (Tree prefix) will not compile

<!---->·    <!---->Natural ordering of Strings from low to high: space, numbers, all uppercase letters, underscore, all lowercase letters

 

Generics

<!---->·    <!---->Legal generic method declaration:  public static <X, Y extends X> boolean isPresent(X x, Y[] Y)

<!---->·    <!---->Generic types (within “<  >”) do not get upcast by the compiler, but base types (before the “< >”) using generics can be implicitly upcast (and downcast?)

<!---->·    <!----><? extends Animal> means the generic can be assigned an Animal or any subclass of Animal

<!---->·    <!----><? super Animal> means the generic can be assigned an Animal or any superclass of Animal

<!---->·    <!---->List<?> is the same as (means) List<? extends Object>

<!---->·    <!---->You cannot add objects to a Collection using generics <?> syntax.  Compilation will fail if the generic type is not known at compile time.  However, you can add to Collections using generics with <? extends MyObject> syntax

<!---->·    <!---->In method declaration that can accept generics syntax, generics must be declared before the return type: public <T> void makelist(T t){}

<!---->·    <!----><T super Dog> not <? super Dog>

<!---->·    <!---->It is VALID to assign non-generic classes to generic classes LinkedList<Integer> IList = new LinkedList() – gives warnings on compilation but runs without errors

 

Exceptions

<!---->·    <!---->Exceptions that are not handled propogate (from main they propogate to the terminal) AFTER any finally

<!---->·    <!---->Throwable is a class and NOT an interface, so it’s LEGAL to write new Throwable()

<!---->·    <!---->Programmers frequently throw IllegalStateException, NumberFormatException, and IllegalArgumentException, AssertionError, not the JVM.  Know when to throw these.

<!---->·    <!---->JVM usually throws NullPointerException, ArrayIndexOutOfBoundsException, ClassCastException, ExceptionInInitializerError, StackOverflowError, NoClassDefFoundError, and any other Error.  Know when these are thrown.

<!---->·    <!---->catch(Exception e) {} will catch all exceptions, including Runtime Exceptions that don’t need to be caught to compile

<!---->·    <!---->FileNotFoundException extends IOException (which is a RuntimeException)

<!---->·    <!---->Constructors can throw exceptions

 

Command Line/Dev Environment Stuff

<!---->·    <!---->For running programs from the command line, the classpath must include the directory to find the class file of the specified program (containing main) and the directories (root directory of any packages) for finding any class files referenced by the main program

<!---->·    <!---->Can’t call “super.super.someMethod()” – will not compile

<!---->·    <!---->It is LEGAL to import only static methods with static imports – e.g. “import static java.util.Collections.sort”, then in code “sort(arrayList)”

<!---->·    <!---->Static imports must include, either with a wildcard (*) or explicitly, the members that will be referenced.  So “import static java.lang.Math” is not a valid static import, but “import static java.lang.Math.*;” or “import static java.lang.Math.random” are valid static imports

<!---->·    <!---->jar files and “-classpath” (or “–cs”) can be used with both java and javac

<!---->·    <!---->Command line calls to run a class (using java) must include package names (e.g. java –cp classes com.players.MusicPlayer)

 

Threads

<!---->·    <!---->Thread name does NOT have to be unique

<!---->·    <!---->To synchronize correctly, usually synchronize in method declaration, on “this”, or on a static object, but do NOT choose instance or local variables since each object has it’s own lock.

<!---->·    <!---->A synchronized method can be overridden by a non-synchronized method and vice-versa

<!---->·    <!---->Abstract methods can’t be synchronized

<!---->·    <!---->Objects have locks, Threads do NOT have locks

<!---->·    <!---->Collections Framework interfaces CAN’T be serialized (probably no interface can be serialized?), but all of the implementing classes can

<!---->·    <!---->Invoking start() multiple times on a thread will compile but throw an IllegalThreadStateException at runtime

<!---->·    <!---->Only methods and blocks can have synchronized modifier, not variables or classes.  However, you can synchronize on (the lock of) an object that may be a variable using synchronized(myObject) – synchronizes on lock of myObject

<!---->·    <!---->synchronized(this) says to synchronize on current object and synchronized(MyClass.class) synchronized on the class (it’s equivalent to synchronizing a static method)

<!---->·    <!---->There are separate locks for the class (just one for class) and for the objects of the class (can be many for objects – 1 for each object)

<!---->·    <!---->A thread must have a lock on the object on which the wait() method is to be invoked (but then it gives up the lock as soon as wait() is invoked)

<!---->·    <!---->Call start() on a Thread instance, not a Runnable instance

<!---->·    <!---->A lock is not released when a thread goes to sleep

 

Assertions

<!---->·    <!---->It’s considered OK to throw AssertionError explicitly (why? does this mean outside of an assertion)

<!---->·    <!---->OK to use assertions to verify the arguments of private methods

<!---->·    <!---->Assertions statements should not alter the value of any variable.

<!---->·    <!---->the expression after the “:” in an assert statement must have a value, so a method call must have a return value, and after the colon can’t be empty

<!---->·    <!---->For assertions to execute, code needs to be both compiled AND run with assertions enabled

 

Inner Classes

<!---->·    <!---->Inner classes can be abstract, and any abstract methods in abstract classes can be defined with a concrete anonymous subclass

<!---->·    <!---->Correct static “inner” class instantiation syntax:  new Outer.TestInner() – constructor for Outer will never run.  If it’s not a static inner class, then syntax needs to be new Outer().new TestInner()

 

Garbage Collection and finalize()

<!---->·    <!---->Garbage Collection is performed by a daemon thread

<!---->·    <!---->An object created and accessed locally may only be eligible for garbage collection when the method returns IF the object is not passed out of the method

<!---->·    <!---->If an array of size 2 that refers to 2 objects is eligible for garbage collection, then 3 objects are actually eligible for gc – the array object and the 2 objects it references

<!---->·    <!---->When an object is passed to an unseen method, we can’t be sure the object is eligible for gc anywhere below the method-calling code, b/c the method could pass the object on to threads.

<!---->·    <!---->The finalize() method can be overloaded, but only the no-arg finalize() method will be called by the JVM.

<!---->·    <!---->The finalize() method is usually used to free up resources other than memory

<!---->·    <!---->Live object references in a finalize() method can “resurrect” an object

<!---->·    <!---->The finalize() method is guaranteed to run once and only once before the garbage collector deletes an object.  However, there is no guarantee that the object will ever be garbage collected, so there is no guarantee that finalize() will run.