Using more specific types in code visible to GWT frontend
Hello, in GWT world, being more specific (e.g. using ArrayList instead of just List) is preferred since the GWT compiler doesn't need to introspect all possible subtypes and include them in the generated JavaScript. Using too "generic" types is one of the main reasons of significant GWT-generated JavaScript size. I'd like to improve this and I'm wondering what others think. For example, in BusinessEntity interface, is there any reason why <T extends Serializable> and not e.g. <T extends Guid> ? If the GWT compiler sees a reference to Serializable type and it isn't obvious what's the instance type behind it, it includes *all* Serializable subtypes into the generated JavaScript. You can probably imagine how many of those are visible to GWT compiler via Java classpath. Another example is query & action result allowing arbitrary List/Map/Set impl. to be passed through GWT RPC. What about limiting us to ArrayList, HashSet and HashMap for GWT RPC transfer? Please be aware that usual Java performance tips do not apply to GWT world due to Java-to-JS compilation. (And therefore, using LinkedList instead of ArrayList has no practical effect aside from bigger JS footprint.) I'd like both frontend and backend maintainers to share their thoughts. Alexander's UI redesign efforts [1] are well on their way into the master branch and it's a good opportunity to improve existing GWT frontend, making it smaller & faster for our users. [1] https://gerrit.ovirt.org/#/c/75669/ Thanks! Vojtech
Hi, the part I would be worried about is that entities are also used on the Java side of the engine. And the generic type recommendations and guidelines say exactly the opposite for Java (declare generic, use whatever impl you need). It seems to me that some form of UI specific DTOs might improve the separation and performance here. Changing all entities to use specific types would be a HUGE patch as it would probably affect almost every single file we have in the engine. Or maybe: Can we use some kind of compiler extension to rewrite the source code for the GWT side only? I would really prefer if the Java side of out logic and DAOs was not mangled just to make GWT happier. -- Martin Sivak SLA / oVirt
On Fri, Jun 2, 2017 at 5:44 PM, Martin Sivak <msivak@redhat.com> wrote:
Hi,
the part I would be worried about is that entities are also used on the Java side of the engine. And the generic type recommendations and guidelines say exactly the opposite for Java (declare generic, use whatever impl you need).
First of all, many thanks for your feedback, Martin! I agree with you completely. The Engine/Java side should follow standard Java best practices. The Engine/Java world is very different from GWT/Java world, but unfortunately, they are coupled via GWT RPC run{query,action} mechanism.
It seems to me that some form of UI specific DTOs might improve the separation and performance here. Changing all entities to use specific types would be a HUGE patch as it would probably affect almost every single file we have in the engine.
Well, there are (at least) two possible solutions: 1, the one you've suggested - make the separation explicit by transforming objects from Engine/Java world (such as business entities) into DTOs which are optimized for GWT/Java world 2, tweak GWT compiler's handling of Java types without touching existing code - blacklist generic types, whitelist only some specific impl's of those types (note: this is a built-in GWT feature) Given the existing complexity, I'd like to try out the second approach first and see how far we can get. For example, add a GWT-specific rule that replaces <Whatever>List to ArrayList during GWT compilation (affects generated JS code), plus blacklist <Whatever>List and whitelist ArrayList in GWT RPC serialization policy (affects GWT RPC request validation). This approach can be applied to any other types, all the way up to the `Serializable` interface. The separation by DTO approach is, however, more correct from design perspective. I'll give it more thought. Thanks for bringing it up.
Or maybe: Can we use some kind of compiler extension to rewrite the source code for the GWT side only? I would really prefer if the Java side of out logic and DAOs was not mangled just to make GWT happier.
What about limiting us to ArrayList, HashSet and HashMap for GWT RPC
That compiler extension is already possible, it's a built-in GWT feature :-) However, we still need to know if it's OK to treat all Lists as ArrayLists on frontend, for example. That's the motivation behind my question: transfer? More generally, if we can think of any non-standard, non-obvious `Serializable` type that is needed on the frontend, in order to safely construct the whitelist/blacklist for GWT code. That's because I'm suspecting that our GWT code does reference `Serializable` type and we *do* need to blacklist it and whitelist only specific types we need. (The <Whatever>List to ArrayList approach will have no impact if GWT still sees us using `Serializable` interface.)
-- Martin Sivak SLA / oVirt
participants (2)
-
Martin Sivak -
Vojtech Szocs