I have read that for GWT, specifying methods to return a concrete implementation, for example:
public ArrayList<String> getList();
instead of the normally-preferred “abstract interface”, for example:
public List<String> getList();
results in GWT producing a smaller compiled javascript file, because the client (ie js) code doesn’t have to cater for all known implementations of the interface (in the example of List, the client code would have to be able to handle LinkedList, ArrayList, Vector, etc), so it can optimize the js by not compiling unused implementations.
My closely-related questions are:
- Is this true? (the following questions assume it is true)
- Is the optimization per-class that uses interfaces, or per application? ie
- Do I see a benefit just refactoring up one class? or
- Do I only see a benefit once all client classes are refactored to not use interfaces?
I just did a test based on the sample app generated by webAppCreator, but I added 3 simple services that returned either
List<String>orArrayList<String>, depending on the build.The results were that having all services use
ArrayList<String>saved about 5Kb from the compiled javascript over having any mix of the return types.That proves the saving is real and per-app (not per-service).
It also show how much it saves (in this case).