Rinav G's List: Java

• private static final long serialVersionUID = 1L
• and it is still there even after the program finished. Let’s see if we can read that file once again, this time without creating it first.
• Now, let’s see what happens, when we change the serialVersionUID value and try to deserialize once again our file. Change the line 2 in the class SerializeMe so that serialVersionUID contains now 2 instead of 1:
• static final
• serialVersionUID = 2L;
• Exception in thread "main" java.io.InvalidClassException:
• As you can see, this time the deserialization didn’t go well. ObjectInputStream complained about the serialVersionUID being changed.
• How does he know that it changed? If serialVersinUID is static, then it should not have been serialized in the first place, and there should be no information about the previous value 1 during the deserialization, right? Well, serialVersionUID is an exception to the rule that “static fields don’t get serialized”.
• Moreover, if there is no serialVersionUID officially declared in the class to be serialized, compiler automatically adds it with a value generated based on the fields declared in the class.
• The deserialization of that object does not necessarily have to occur exactly after serialization. It can occur after a few months or on a completely different JVM
• there is a chance that the class declaration has changed between serialization and deserialization.
• It checks if the data read from the input stream is compatible with the current definition of the class.
• when the visibility of a field changes, the serialVersionUID changes too.
• sometimes you just want for some reason to forbid deserialization of old serialized objects,
• you might tend to write it once for every serializable class ( or have it generated by the IDE ) and forget about it. WRONG !!!
• If you write it once and don’t take care to update it when necessary, you loose all the merits of serialVersionUID.

14 more annotations...

• Auto-loading of JDBC driver class
• In JDBC 4.0, we no longer need to explicitly load JDBC drivers using Class.forName(). When the method getConnection is called, the DriverManager will attempt to locate a suitable driver from among the JDBC drivers that were loaded at initialization and those loaded explicitly using the same class loader as the current application.
• Service Provider mechanism (SPM).
• META-INF/services directory.
• META-INF/services/java.sql.Driver.
• the META-INF/services/java.sql.Drive
• java.sql.Driver.

5 more annotations...

• Package java.util.concurrent.atomic 

   A small toolkit of classes that support lock-free thread-safe programming on single variables.

• java.util.concurrent.atomic 
   Class AtomicInteger

   

  java.lang.Object   java.lang.Number       java.util.concurrent.atomic.AtomicInteger 
• An int value that may be updated atomically. See the  java.util.concurrent.atomic package specification for  description of the properties of atomic variables. An  AtomicInteger is used in applications such as atomically  incremented counters, and cannot be used as a replacement for an  Integer. However, this class does extend  Number to allow uniform access by tools and utilities that  deal with numerically-based classes.

• A small toolkit of classes that support lock-free thread-safe programming on single variables. In essence, the classes in this package extend the notion of volatile values, fields, and array elements to those that also provide an atomic conditional update operation of the form:  

    boolean compareAndSet(expectedValue, updateValue); 
• The specifications of these methods enable implementations to employ efficient machine-level atomic instructions that are available on contemporary processors.
• int incrementAndGet()  
             Atomically increments by one the current value.
• Atomic classes are not general purpose replacements for java.lang.Integer and related classes. They do not define methods such as hashCode and compareTo. (Because atomic variables are expected to be mutated, they are poor choices for hash table keys.)

6 more annotations...

• Writing your own logging framework is the perfect  coding crime
• Even the Sun engineers fell into this trap. Prior to Java 4,  we had a perfectly good logging framework in Log4J. However,  instead of adopting this into the standard Java distribution,  we ended up with java.util.logging. There are lots of Java  logging frameworks available, even meta-logging frameworks  like SLF4J and Jakarta Commons. These are supposed to  abstract the logging frameworks so you can change the  implementation without touching your code.
• Logging Levels
• In Log4J for example, we have six default levels,  FATAL, ERROR, WARNING, INFO, DEBUG and TRACE.
• Since it is tricky assigning the correct levels in our code,  we should regularly do code reviews with specific emphasis on  logging levels.
• We should be able to adjust the log levels of our individual  components at runtime without restarting our application.
• Silent Operation

5 more annotations...