10:33 a.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