Time to remove GWT-RPC from WebAppCreator sample app?

154 views
Skip to first unread message

Thomas Broyer

unread,
Apr 20, 2017, 2:33:48 PM4/20/17
to GWT Contributors
Should we start thinking about removing GWT-RPC from our sample app? (and probably tutorial on the web site)
What would we replace it with though? I'd suggest plain old HTTP with JSON and JsInterop; but what about the server? Using HTTP POST with manually-encoded application/x-www-form-urlencoded data and org.json (or AutoBean?) to encode the response as JSON?

Colin Alworth

unread,
Apr 20, 2017, 4:05:37 PM4/20/17
to GWT Contributors
Dissenting opinion, mostly for the sake of discussion (though I'll admit to being an RPC fanboy too):

This came up in discussion in ##gwt today, from the other perspective - the stockwatcher app uses JsonpRequestBuilder, which is incompatible with JsType without some seriously fugly casts (as far as we could figure out), and hasn't been updated since GWT 1.6 was new.

I might almost take the other perspective - at least RPC (with or without @JsType annotations so the loaded objects could be used in external JS) will at least work in modernized gwt, but JsonpRequestBuilder requires some hoops to jump through to make sense. Anything talking about Element or other JSOs is likely to become confusing as well in the very near future, as JSO.cast() is bound to JSO subtypes, so you need to cast first to Object and then to the appropriate JsType.

  JsArray<JavaScriptObject> results;//from JsonpRequestBuilder callback
 
MyJsType instance = (MyJsType) (Object) results.get(0);//or a JSNI 'cast', which also won't exist in GWT 3

In contrast (donning my asbestos suit...) RPC still works as-is today and doesn't have any serious GWT-compatible future-proof competition in terms of sending graphs of plain Java objects. There appears to be the risk that GWT 3 may not support the so-called "violator pattern", but until we have the ability to actually run the compiler, there is no guarantee of that - at worst, they can be @JsTyped so the field names won't be renamed... I think. A future APT-built set of serializers could walk getters/setters and provide the same graph serializer that RPC gets us today (and possibly even with less terrible errors...).

If we get rid of RPC docs and samples because Generators are on the way out, but replace with RequestBuilder or JsonpRequestBuilder, we're just trading one "it probably won't work in 3" for another. Plus, the same logic says references to Widgets/UiBinder/etc should be removed as well. If it's just for the "there is another way to do it", why be opinionated? I could see a disambiguation page to discuss the pros/cons (and relative future-proofness, or lack thereof), but outright removing seems... harsh.

On the other hand, if we have tools (i.e. outside of gwt-user) that work with only jsinterop and APT, my points make a lot less sense, but I don't think we're there yet.

--

As replacement goes, I like AutoBeans for nearly the same reason as RPC - the server-side de/serialization is consistent, predictable, and supports Java conventions and apis. Alas, it has the same problems of being rooted in the past - JsoSplittable, generators. You can make JAX-RS methods work, but the surprise gotchas (server supports polymorphism but client doesn't? No easy primitive wrapping or enums? No Java collections, and odd behaviors in array instanceof? etc) seem like they would require both that the doc be opinionated on which server serialization tool is used, and provide the laundry list of things to watch out for. Personally I'd like to see a plan around a GWT 3 capable tool that addresses the entire experience before talking about removing RPC - and then take JSOs, JSONObject, AutoBean, RequestFactory, etc all out at the same time.

Jens

unread,
Apr 20, 2017, 8:28:24 PM4/20/17
to GWT Contributors
I don't think so. There are more important questions to think about, like:

How will GWT 3 look like? Which features will carry over? Who ports what? When to start porting, given that JsInterop 1.0 and a beta of jsinterop.base is available? Do we create a new repository for GWT 3 to give it a clear start with a proper build system? Which one? Do we create a new repository for emulation that can be used together with J2CL as a bare minimum for people not using GWT? Would we back port emulation to GWT 2.x once we push new stuff to the dedicated emulation repository? Does gwtproject want to provide an official build tool plugin given that it might need one anyways to build itself? 

IMHO there are lots of things to be organized and discussed even with J2CL not being released. Does the steering group work on it? Why there are no meeting minutes for nearly a year now? I am pretty sure Google would give you more insight into J2CL as they are also interested in porting their apps to J2CL so you should be able to create a plan.

But to answer your question: I never really used WebAppCreator so personally I would just let it generate the project structure with a very simple Hello World label. If I want to know how to communicate with a server, the web site should tell me in form of a tutorial which describes which files and packages to create/modify starting with a nearly empty project created by WebAppCreator. For a more sophisticated quick demo, people could look at GWT 2.x SDK example projects. If we have any that uses GWT-RPC thats fine, it works and will exist for the next years. Maybe adding a warning on the GWT-RPC documentation with regard to GWT 3 might be useful.

-- J.
Reply all
Reply to author
Forward
0 new messages