<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 2, 2017 at 5:44 PM, Martin Sivak <span dir="ltr">&lt;<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
the part I would be worried about is that entities are also used on<br>
the Java side of the engine. And the generic type recommendations and<br>
guidelines say exactly the opposite for Java (declare generic, use<br>
whatever impl you need).<br></blockquote><div><br><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">​First of all, many thanks for your feedback, Martin!​</div><br><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">I agree with you completely. The Engine/Java side should follow standard Java best practices.<br><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">The Engine/Java world is very different from GWT/Java world, but unfortunately, they are coupled via GWT RPC run{query,action} mechanism.<br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It seems to me that some form of UI specific DTOs might improve the<br>
separation and performance here. Changing all entities to use specific<br>
types would be a HUGE patch as it would probably affect almost every<br>
single file we have in the engine.<br></blockquote><div><br><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Well, there are (at least) two possible solutions​:<br><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">1, the one you&#39;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<br><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">2, tweak GWT compiler&#39;s handling of Java types without touching existing code - blacklist generic types, whitelist only some specific impl&#39;s of those types (note: this is a built-in GWT feature)<br></div><br><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">​Given the existing complexity​, I&#39;d like to try out the second approach first and see how far we can get.<br><br>For example, add a GWT-specific rule that replaces &lt;Whatever&gt;List to ArrayList during GWT compilation (affects generated JS code), plus blacklist &lt;Whatever&gt;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.<br><br>The separation by DTO approach is, however, more correct from design perspective. I&#39;ll give it more thought. Thanks for bringing it up.<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Or maybe: Can we use some kind of compiler extension to rewrite the<br>
source code for the GWT side only? I would really prefer if the Java<br>
side of out logic and DAOs was not mangled just to make GWT happier.<br></blockquote><div><br><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">​That compiler extension is already possible, it&#39;s a built-in GWT feature :-)<br><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">However, we still need to know if it&#39;s OK to treat all Lists as ArrayLists on frontend, for example. That&#39;s the motivation behind my question:<br><br>&gt; What about limiting us to ArrayList, HashSet and HashMap for GWT RPC transfer?<br><br>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&#39;s because I&#39;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 &lt;Whatever&gt;List to ArrayList approach will have no impact if GWT still sees us using `Serializable` interface.)<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
--<br>
Martin Sivak<br>
SLA / oVirt<br>
</blockquote></div><br></div></div>