Every information thread talking about GC dump for a spawned Java VM talks about the command
java -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc -cp $CLASSPATH <fqcn-main-class>
You could look at what is the output format, and what it means here. The timestamps logs the time in seconds and it would be cumbersome to figure out from when the application is running. Hence in order to we tweak in the date forma, we got to use this command instead:
java -XX:+PrintGCDetails -XX:+PrintGCDateStamps -verbose:gc -cp $CLASSPATH <fqcn-main-class>
where the datestamp fomat would be in yyyy-MM-ddTHH:mm:ss.SSS<+-GMT_Difference>.
As part of the Hibernate Search, I happened to get an insight into various core classes of Apache Lucene. Here is the structural model that I feel could be used for reference.
As put clearly on what adds to cyclomatic complexity in a Java class method here, and to keep the metric around 5-6, following are the refactoring rules we could follow:
1) Keep the method size to less than 25 lines of code.
2) Look at the detail design options of having recursion for intertwined looping constructs with complex logic in case if any.
3) Have fewer points of return by declaring an object of return type and single path of execution to the return statement.
4) Use ternary operations for conditional assignments.
5) Catch exceptions judiciously. Dont catch runtime exceptions, and catch only relevant checked exceptions, throwing other non-relevant exceptions to the caller. This increases cohesions of the method, thus reducing complexity.
As put in the previous blog, runtime type erasures for java generics offer both advantages and annoyances. Lets try exploring its effect on runtime type casting.
Assume we have a code snippet with explicit typecasts and implicit assumptions
private void callMethod(Object array)
{ List<Integer> copiedArray = (List<Integer>)array;
System.out.println(”First Element ->”+copiedArray.get(0));
}
private void callMethod(Object array)
{ List<Integer> copiedArray = (List<Integer>)array;
System.out.println("First Element ->"+copiedArray.get(0));
}
private void callingMethod()
{ List<String> stringArray = new ArrayList<String>(2);
stringArray.add(new String("hello"));
callMethod(stringArray);
}
The class containing these method would compile and run without complaints. Reason: During compile time, compiler cannot detect the linked caller and callee parameter types, and during runtime, 'runtime type erasures' ensure the type of a casted object is not maintained in the constant pool. Let us slightly modify the calling method as below.
private void callMethod(Object array)
{ List<Integer> copiedArray = (List<Integer>)array;
System.out.println("First Element ->"+copiedArray.get(0).getClass()); // call a method on the fetched object
}
This would throw ClassCastException during the runtime, as the actual type checking by the JVM is done then.
With introduction of Generics in Java, type checking in Java opened up a can of complex variations and concepts. During the compile type, the compiler enforces stricter type checking for a generics implements. That is
List<String> listOfStrings = new ArrayList<String>(1);
listOfStrings.add(new Integer(1)); //will throw a compilation error
However during the runtime, the JVM doesnt maintain type information about generics, and this is ‘type erasure’. So effectively a code snippet such as this
List<String> listOfStrings = new ArrayList<String>(1);
listOfStrings.add("HelloWorld");
String addedElement = listOfStrings.get(0);
would get converted to in
List listOfStrings = new ArrayList(1);
listOfStrings.add("HelloWorld");
String addedElement = (String)listOfStrings.get(0);
Behind the scenes, there are 2 passes of compilation, in which the first pass handles the type checking, and in the second pass, the type information is erased and written to the class file.