11:22 a.m.
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
11:44 a.m.
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
12:33 p.m.
On Fri, Jun 2, 2017 at 5:44 PM, Martin Sivak <msivak(a)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.
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:
What about limiting us to ArrayList, HashSet and HashMap for GWT RPC
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
2761
days inactive
2761
days old
2 comments
2 participants
participants (2)
-
Martin Sivak -
Vojtech Szocs