Thursday, July 14, 2016

GWT RPC's future

This post is about why I do not think that GWT RPC is something valuable to be carried forward.
I am also being slightly harsh with GWT RPC which has served many GWT applications as a good RPC mechanism. Please keep in mind that this post is not about assigning blame, I do think that the engineers who designed GWT RPC did a great job, they just had other more important goals in mind.

When I first discovered GWT RPC in somewhat 2008 I thought it was magical. Send all my Java objects over the wire and just use them on the client side. All I need to do is define a simple interface. I loved it.

But as time went by I have started to dislike GWT RPC more and more. This blog post is about the bad choices that GWT RPC has made and why I do not think its a good choice to be carried forward for applications that transpile Java to JavaScript. However this does not mean that its not possible to port it forward (with some changes), but I think its not worth it there are simply better alternatives.

Bad choices


GWT.create call type inheritance broken

AsyncChronousVersion instance = GWT.create(SynchronousVersion.class);
Why do I need to pass in the synchronous version? From a type perspective this does not make any sense what so ever.
The synchronos version extend the RemoveService interface, the asynchronos version did extend nothing. Why not simply use the Asynchronous version all the way?
If you know what a GWT.create call looks like in the compiler you realize that this is really broken.

Exploding code size

Let's take a look at the second problem that GWT RPC has that is way more severe.
Assume we have this simple RPC interface:

public interface MyServiceAsync {
  void doSomething(List strings, AsyncCallBack callback);
}

The interface defines a simple method that takes a list of strings. The problem with this code becomes apparent when we take a look at the serializers and deserializers that have to be generated for this class. Since we need to have a serializer for every concrete type that we have in the program, you end up with potentially hundereds of serializers just for this one method.
The GWT team always recommended to be as specific as possible to get rid of this flaw, but this is against a core design principle in Java. We want List on the interface, not ArrayList.

Doing a simple search for subtypes of ArrayList in a hello world GWT applications returns 16, this is obviously a bad choice.

Version skew during deployment

Because of the need for serializers that were specific to your current applications, GWT RPC had a serious issue with version skew. Make a slight changes to your problem and you might have ended up causing GWT RPC to fail between these version of your app. When you have multiple thousand servers running you will always have an old client talking to a new server or an old client talking to a new server. Not dealing with this is unacceptable for a RPC system and has cost many teams at Google headaches.

Slow compiles due to global analysis

If you want to generate all the serializers of a type you need to have global knowledge of your program. You need to be able to answer questins like:

  • "Who is implementing this interface?"
  • "Who is subclassing this class"
This means that you can not incrementally compile GWT RPC code since you would not be able to answer these questions correctly. The only reasons that super dev mode works with GWT RPC is that we do the initial slow full world compile and then keep track of these types as you update your code.If you want really fast compiles, which we want for GWT 3.0, you really do not want any global knowledge.

GWT RPC can not be done with a Java annotation processor

All other GWT code generators can be changed to be Java annotation processors, since they do not require global knowledge. Since GWT RPC requires global analysis it can not be easily ported.

But I really like GWT RPC, what can I do?

Well as I said earlier in this post, you can port it to an APT, but you need to make changes to it:

  - Change the interface to list all the types it needs so you do not require global knowledge
  - Remove the synchronous or asynchronous interface and generate one from the other
  - Replace the GWT.create call
  - Make the serialization format compatible with different versions of your app, by the way this is what we do with GWT proto RPC, which unfortunately is not open source.

This could potentially look like this:

public interface MyServiceAsync {
  void doSomething(@Serializer(accept = {ArrayList.class}) List strings, ...)
}

// MyServiceAsync_Factory is generated by an APT
MyServiceAsync service = MyServiceAsync_Factory.create();


I hope this blog post helps people that really like GWT RPC to understand why there are better choices one can make for a RPC mechanism and why we should be striving to have something better.

Monday, June 2, 2014

gwt-phonegap 3.5

I just finished the gwt-phonegap 3.5 releases and pushed it to maven central.

This is now fully compatible with Phonegap 3.5 and  GWT 2.6. It contains many bug fixes and improvements.

This version fully works with mgwt and already uses the new mgwt 2.0 for its showcase.
As always you can get the new version from google code or from maven central: 

<dependency>
      <groupId>com.googlecode.gwtphonegap</groupId>
      <artifactId>gwtphonegap</artifactId>
      <version>3.5.0.0</version>
</dependency>

Sunday, January 12, 2014

mgwt / gwt running on a the Tesla Model S

If you come the Silicon Valley these days you will spot Teslas everywhere, but not here in Germany. A couple of days ago I saw my first Tesla driving around in Munich, being a car nut I immediately needed to get my hands on one here.
I actually would like to replace my old BMW 5 series with something new and I was favoring a BMW M5 very much. When talking about cars in the US, I was always telling colleagues that a Tesla would not work in Germany for two reasons:

  • You will run out of battery on a german autobahn pretty soon, since driving high speeds is very energy consuming.
  • It does not have enough top speed (only 210 km/h)


Tesla just solved the battery problem by offering battery swaps as well as extending their super charger network. Today I can already drive from Munich to Dusseldorf without problems and this network is growing rapidly. Having the battery swaps means that you do not need to care about range anymore since getting new energy will only take 90 seconds.
The oomph that is provided by the performance plus version with its 600 Nm is quite exciting to drive, but it is still lacking in max speed. If I spent 125 thousand euros on a car, I expect it to at least go 250 km/h or even more. A BMW M5, a Porsche 911 turbo, Mercedes AMG 63, all these cars can easily hit 300 km/h on a german autobahn. This is not a theoretically number, people actually drive this fast in Germany. This is still a problem for Tesla in Germany, but other than that I would now prefer a Tesla any time over the other cars and will probably soon get one.

MGWT / GWT on the Tesla Model S


    After driving the car I also wanted to see how much the onboard system can actually do. This is running a version of the QT webkit based browser. The complete mgwt showcase was working and you could even think about using a Phonegap approach to build UIs for the car.
    Here is a picture of mgwt running:


    How cool is that?

    Thursday, January 2, 2014

    Profiling GWT applications with v8 and d8

    The v8 JavaScript engine has a command line version called d8 that can be used as a profiler.
    It can help you spot performance problems with your JavaScript in many different ways. If you want to get a good overview of how to profile JavaScript, here is a Google I/O talk on the subject: "Breaking the JavaScript speed limit with v8".
    Unfortunately the d8 profiler was not very useful for GWT applications (or any application that was compiled to JavaScript) in the past, since it highlighted problems in JavaScript with line numbers, which does not make a whole lot of sense for a GWT application. Compiling in pretty mode was no option either, since different code layout will lead to different optimizations in v8 (Currently v8 backs our of optimizing a function if it is too large, also counting comments). And of course you want to profile the same code that will be run by your users.

    This is why we added source maps support to the v8 profiling tools. Using a special GWT linker you can now profile your GWT application in d8 and get back Java line numbers. This is one of the things that we did to help the our colleagues to make Google Sheets as fast as possible.

    Here is how you can profile your GWT application:

    Build v8 locally

    Build your version of v8 using these instructions. After that make sure that d8 (most likely under out/native) and the tickprocessor (tools/mac-tick-processor or tools/linux-tick-processor or tools/windows-tick-processor.bat)  are available in your path.

    Create an entrypoint that runs your performance critical code

    Create a new GWT module with an EntryPoint that calls your performance critical code. In your gwt.xml file you need to add the linker, set the user agent and enable source maps:

    <define-linker name="d8" class="com.google.gwt.core.linker.D8ScriptLinker"/>
    <add-linker name="d8" />
    <set-property name="user.agent" value="safari" />
    <set-property name="compiler.useSourceMaps" value="true"/>

    Compile your GWT app

    Now you can just invoke the GWT compiler for your module. It will produce three files that you should move into one directory for your profile:
    • selection script: .nocache.js
    • actual program: .js
    • sourcemap: (located in WEB-INF/deploy//symbolmaps/_sourceMap0.json)

    Run the profiler

    This blog post does not cover all the details on how to use d8, this is much better covered by the v8 team, but most of the times for a GWT app you want to run:

    d8 -prof <modulename>.js

    (You want to make sure that all files are in the same directory and that you are running d8 from that directory)
    This will create a file called v8.log that contains all the information from that profile run. Now we will use the tick processor to analyze this file, but we also need to pass it the source map, so that it can give us Java line numbers:

    linux-tick-processor --sourceMap=<path to sourcemap> v8.log

    This will output a complete profile of your JavaScript. It will show you how much time you spend executing JavaScript (and which functions / Java methods), executing C++ or in library code. It also contains a drill down view of your profile.

    Sum up

    With the changes we made to v8 and GWT you can now use the great v8 toolchain to spot performance problems in your GWT applications. These tools will also allow us to improve the way the GWT compiler translates code in order to make it run faster as well as improving the standard libraries that come with GWT.  You can look forward to your GWT applications running faster in the future.

    Tuesday, December 31, 2013

    GWT.create conference aftermath

    I finally found some time to write on my impression of the first GWT.create conference in San Francisco and Frankfurt. I have been involved very early with the conference and helped in some aspects to make this a success, but it turned out even better than all the people behind GWT.create hoped.

    Before I go into any more detail let me quickly thank Vaadin, who not only invested a big amount of money and time to make this conference a success, but also made sure that this conference was not biased towards Vaadin and was a good platform for all people of the GWT community (such as Sencha, Readhat and others). 

    In both locations we had 646 attendees, which is huge for a first time conference, but what I liked even more is the fact that we had very good GWT content:  All the talks got an average rating of 4 out of 5.
    We had very exciting talks from many GWT team members that showed where we want GWT to be in one or two years time. 
    All the slides are already published on gwtcreate and talks will be published on youtube over the coming weeks, so if you could not make it, you still get a chance to watch the talks.

    One of the most valuable session was the panel discussion, in which we could listen to the communities input. I think the discussion around super dev mode and IE8 were very valuable and we will take our conclusions from that.
    I personally spoke to so many GWT developers that were building amazing things using GWT. I was completely amazed. One of the most notable things to me was a camera which uses GWT for its UI.

    Some thoughts on talks

    Ray's keynote was designed to give people an overview on some of the cool stuff we are working, such as:
    • JsInterop & zero effort JsInterop
    • Performance boosts
    • New Google products covering several platforms using GWT, such as  Google Spreadsheets
    • GWT 3.0
    • Java8 support
    GWT has been designed in 2006 to leverage the Java ecosystem for building client side web applications. At this time there was no JavaScript ecosystem (debugging was done with alert statements), but in 2014 there is a large JavaScript ecosystem and GWT developers should be able to benefit from this without any major efforts. This is why we are going to introduce a new way of consuming well written JavaScript libraries (JsInterop) without any extra work from developers. This is very exciting to watch in the keynote.
    Goktug's web components talk showed off how to use this for a new widget system in GWT. I think this was one of the most impressive talks on the conference, since it showed how easily GWT can sit on top of the JavaScript ecosystem.
    The new Java8 syntax with closures actually allows us to be more concise than JavaScript. We can finally get rid of all those nasty inline interfaces for callbacks.
    Ray also introduced one new Google product which is leading the way with writing once in Java and running your code everywhere: Google Sheets.
    Brian showed off his work on super dev mode and what we are going to do to make it as good or even better as dev mode. If you combine this with John's and Roberto's work to make the GWT compiler work incrementally, we have a very good story for developer productivity in 2014.
    Matthew presented on the status of the GWT open source project. We are seeing strong contributions from outside of Google. There was one we specifically wanted to highlight. Julien Dramaix presented with me on CSS3 and GSS support in GWT, which he did as a complete open source contribution. Erik presented on testing with GWT and his great open source project gwt-mockito and Rob on an architecture that we use inside of Google for really large applications called Turducken.
    There is so much more great content I want to talk about, but I guess I should leave this to separate blog posts.

    Combine all this work and we have a very good story for GWT in 2014.

    Since GWT.create 2013 was such a huge success, we are already planing on setting up something bigger for 2014. There is still time to get your ideas into the 2014 google moderator.
    I am very happy to see that so many people got involved with this conference and joined us in the contributor workshop. I felt so much appreciation for our work that I am really happy to be working on GWT and with this great community.

    Saturday, March 30, 2013

    gwt phonegap 2.4 released

    Today I got around to release gwt-phonegap 2.4.

    This is now fully compatible with Phonegap 2.4 and  GWT 2.5. It contains the new APIs such as the InAppBrowser and the Globalization API.

    This version fully works with mgwt.
    You can get the new version from github or from maven central:

    <dependency>
          <groupId>com.googlecode.gwtphonegap</groupId>
          <artifactId>gwtphonegap</artifactId>
          <version>2.4.0.0</version>
    </dependency>
    

    Tuesday, December 4, 2012

    GWT Survey results

    Today David Booth came through and together with Vaadin composed the complete results of the GWT survey. A really big thanks for all the work they have done!

    You will discover a lot of comments in the document from me, but let me outline a few important decisions. GWT is very healthy: about 90% of the people doing GWT would choose to use it for their next project as well.

    I was amazed by the number of people who are using mgwt / phonegap to build their projects for mobile.
    The three main things which I felt were missing from GWT (fast compiles, a better CSS3 parser and more great looking widgets) were named a lot in the survey.  The good thing is we are already working on the compile time with super dev mode which will have it's best days still ahead.

    Fast and beautiful widgets that leverage new browser features are still missing, but if you take a look at mgwt this can be done pretty easily. Why don't I build something for desktop as well?

    Those are just some quick thought, read through the report yourself and make up your mind. GWT is healthy with a very good community.