Question

This question is based on an answer I received for another question : https://stackoverflow.com/a/3060233/323357

My understanding is that the use of interfaces to declare return types and parameters types in my services forces the compiler to generate multiple compilation units, which increase my compile time and the size of generated files.

I don’t think this is the case, but does the latest versions of gwt compiler (2.4 – 2.5) have a way to detect unnecessary compilation units…

• for local variables and parameters?

  void someFunction()
  {
      ArrayList<String> list = new ArrayList<String>();
      privateFunction(list); //only use of the private function
  }
  
  private void privateFunction(List<String> list)
  {
      Set<Integer> set = new HashSet<Integer>();
      //do stuff without reallocating list or set
  }
  

• for final members?

  private final Interface member = new InterfaceImpl();
  
  @override
  Interface getInterface()
  {
      return this.member;
  }
  

• for return type?

  List<String> myFunction()
  {
      List<String> ret = new ArrayList<String>();
      //do stuff and fill the list
      return ret;
  }
  

• in services?

  //Service Interface
  List<String> myService();
  
  //Service implementation
  List<String> myService()
  {
      List<String> ret = new ArrayList<String>();
      //do stuff and fill the list
      return ret;
  }
  

Answer 1

Don’t worry about the first 3 of your 4 examples. Usage of interfaces (or classes with many subclasses) on the client side has no cost: Unnecessary classes can be detected easily by analyzing which classes are ever instantiated. If in doubt, examine a compile report.

However, this is impossible in GWT-RPC for server side calls: The client has no way to know, which instances the server will create. Consider that

• the same client can continue to work with updated versions of the server (as long as the service definition is unchanged)
• the server can use reflection to dynamically generate objects: any subtype of the declared type (and this is by the way a major reason why reflection isn’t available on the client side)

The only ways this code size overhead can ever be eliminated, are to either

• give up type safety (you can use JSON based approaches!)
• or analyze the server side during compilation and forbidding to transfer objects that were generated dynamically (this would require a GWT re-compile whenever object instantiation code on the server side changes)