Java and slow XML Parsing

If xml parsing using SAX or DOM appears slow, it is very likely because the parser is trying to download external entities at the point of parsing. A simple fix for this is to implement a custom entity resolver which provides a local reference to the external resource or a dummy one if the external resource is not very important.

For eg. I had to write a small method to validate that an xml is well-formed and so could safely ignore external references, and this is how I had the dummy EntityResolver implementation:

private static boolean isWellFormed(File xmlFile){
 try{
  SAXParserFactory factory = SAXParserFactory.newInstance();
  factory.setValidating(false);
  factory.setNamespaceAware(true);

  SAXParser parser = factory.newSAXParser();
  XMLReader reader = parser.getXMLReader();
  reader.setEntityResolver(new EntityResolver() {
   public InputSource resolveEntity(String pid, String sid) throws SAXException {
    return new InputSource(new StringReader(""));
   }
  });      
  reader.parse(new InputSource(new BufferedReader(new FileReader(xmlFile)))) ;
  return true;
 }catch(Exception e){
  return false;
 }
 return false;
}

Quick toString implementation

Apache Commons Lang provides a quick implementation for a overridden toString method, the output looks clean too - for implementations which are primarily used for debugging purposes:

@Override
    public String toString() {
     return ReflectionToStringBuilder.toString(this, ToStringStyle.SHORT_PREFIX_STYLE);
    }

Java Covariant, Contravariant

    List<T>                                    T  
      Λ                                        Λ 
      |                       if               |
      |                                        |
List<? extends T>                              ?


    List<T>                                    ?  
      Λ                                        Λ 
      |                       if               |
      |                                        |
List<?  super  T>                              T

Junit and Hamcrest - advisable to keep it separate

Junit now comes bundled with some parts of the Hamcrest library - with the Assert.assertThat method which takes in a hamcrest matcher as a parameter

public static <T> void assertThat(T actual, org.hamcrest.Matcher<T> matcher)

along with a series of matchers in the org.junit.matchers.JUnitMatchers class.

Hamcrest core matchers along with the additional matcher libraries it provides are much more comprehensive than the one's that are packaged with JUnit, so at some point it would be natural to import a separate hamcrest library also into the project, and this is where the problems start.

For eg, if I wanted to use some matchers from the JUnitMatchers class and some from the native hamcrest one's, the imports would be along these lines:

import static org.junit.matchers.JUnitMatchers.*;
import static org.hamcrest.Matchers.*;
import static org.hamcrest.CoreMatchers.*;

Unfortunately this will not work, a lot of static methods will start colliding at this point and the imports will have to be much more specific.

A very good work around is to keep junit separate from the hamcrest libraries, a way to do that is to not import core junit libraries but to import junit-dep version of the library where the hamcrest code has been stripped out, this way the hamcrest matchers and the assertThat method can be used without any conflicts with the junit libraries, the imports would look something like this:

import static org.hamcrest.Matchers.*;
import static org.hamcrest.MatcherAssert.*;

and the dependencies in maven would be along these lines:

<dependency>
 <groupId>junit</groupId>
 <artifactId>junit-dep</artifactId>
 <version>4.8.1</version>
 <scope>test</scope>
</dependency>
<dependency>
 <groupId>org.hamcrest</groupId>
 <artifactId>hamcrest-core</artifactId>
 <version>1.2.1</version>
</dependency>
<dependency>
 <groupId>org.hamcrest</groupId>
 <artifactId>hamcrest-library</artifactId>
 <version>1.2.1</version>
</dependency>  

Type inference based on return type

Consider a simple method in java:

private<E> List<E> newArrayList(){
     return new ArrayList<E>();
}

and a test for this method:

List<Integer> anIntegerList = newArrayList();
 List<String> aStringList = newArrayList();

This works without any errors and the type returned by the method is correctly inferred to be an Integer and String resepectively! the reason is - compiler normally infers the type based on the arguments of the method, in this specific case there are no arguments and so the compiler infers the type based on the left hand side of the assignment.

If I really want to force a specific type, then explicitly the type can be specified when calling the method:

List<Double> aDoubleList = this.<Double>newArrayList();

Gauva libraries make use of this inference technique to provide concise static constructors for the collection classes.

Iterator on java Stack appears wrong

Consider the following:

Stack<Integer> stack = new Stack<Integer>();
 stack.push(1);stack.push(2);stack.push(3);
 
 for (Integer item: stack){
  System.out.println(item);
 }

I would have expected the output to be 3, 2, 1 , based on the LIFO property of the stack, however surprisingly the output is 1, 2, 3 !!

This is definitely not an expected behavior. However this is something that Sun cannot fix without breaking backward compatibility either:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4475301