By how much is the compiled js reduced in size by using concrete classes instead of interfaces

Question

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?

It would be easy enough to test this. – Robert Harvey Aug 20 '12 at 02:53 — Robert Harvey, Aug 20 '12 at 02:53

score 6 · Answer 1 · edited Aug 20 '12 at 06:49

The following assumes that you use the interface as part of the signature of GWT RPC service. I think if you do not use the interface in the signature of GWT RPC service, the effect of using classes instead of interfaces should be minimal (e.g. the GWT compiler will only compile the used implementations)

Is this true? (the following questions assume it is true)

Yes, the output of the GWT compiler gets smaller when it 'knows' better which classes might be send from server to client.

Is the optimization per-class that uses interfaces, or per application? ie

In case of GWT RPC, per application.

Do I see a benefit just refactoring up one class?

Yes, one interface replaced by an implementation can reduce generated code size by a few kb, if the interface would require to include code for many classes.

However, apart from using implementations instead of interfaces, also a 'blacklist' of classes can be defined in the module definition file to explicitly circumvent the inclusion of implementations in the generated code: something like

<extend-configuration-property name="rpc.blacklist"
    value="-java.util.ArrayList" />

score 2 · Accepted Answer · answered Aug 20 '12 at 06:09

I just did a test based on the sample app generated by webAppCreator, but I added 3 simple services that returned either List<String> or ArrayList<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).

score 0 · Answer 3 · edited May 23 '17 at 10:34

This doesn't actual to the GWT-compiler in general. Such approach is applied only for classes used with code generation. For example, when using Remote Procedure Calls. See this question for more detail information. Thus, if you declare an interface instead of a concrete class as the return type, the compiler includes all possible implementations in your compiled code. This increases time of compilation and a amount of generated code.

Actually one might develop application using GWT without RPC. In this case compiled code doesn't bloat when using interfaces.

By how much is the compiled js reduced in size by using concrete classes instead of interfaces

3 Answers3