How to Migrate to an Actively Maintained Web Framework
An overview of Google Web Toolkit and reasons for a software migration
Introduction: GWT and Our Customer
While Google Web Toolkit (GWT) has long enjoyed great popularity, it can nowadays be considered outdated for a number of reasons. The problem with using this framework is not only that its popularity has been steadily declining for years, but also that there are clear cutbacks compared to modern frameworks in terms of maintainability, design and an active community. Features that were innovative at the time it was released (2006) are no longer a real advantage compared to modern web frameworks such as Vue.js, Node.js, React or AngularJS.
In our case, we have a client, who operates in the automotive, aerospace, defense and security industries. In our project, further development of a GWT application is desired, whose development started in 2009. Regardless of individual details, the fact that an application can no longer be debugged within a reasonable time is sufficient as a reason for a company to (at least) consider a software migration process. Especially if long-term support is needed.
Apart from that, further drawbacks are explained in detail below. In addition, related projects are presented and the current software architecture as well as a potential architecture at our customer’s in the future are explained in more detail.
Drawbacks of GWT
In theory, there are various reasons for migrating from GWT to a modern web framework. The most important, which have mainly emerged in the course of development during the project phase, are the following (in no particular order):
- Debugging: There is no way to debug the frontend. Add-ons and plugins that were released a few years ago (such as GWT Super Dev Button for Chrome or GWT Eclipse Plugin for Eclipse IDE) no longer work and are no longer updated.
- Building process: This problem arises directly from the previous one (debugging). Since there is no possibility of being able to see changes to the UI code directly on GUI elements, the entire application must always be rebuilt even for small tests, which can take 5–10 minutes depending on the CPU. Of course, build time can continue to increase as more code and tests are written.
- Look: The entire user interface is more reminiscent of Windows XP times than a modern web application. (Of course, this represents a subjective view of the author.)
- Unsupported libraries: Many libraries, such as Google’s Guava (yes, it is supported in theory, but certain parts such as data structures are overwritten by the internal compiler and thus not usable), cannot be used with the GWT compiler, pieces of code have to be completely rewritten or alternative data structures have to be implemented yourself.
- Outdated documentation: The documentation can be considered outdated because, among other things, it refers to a plugin that itself is outdated.
- Community: GWT has been an open source project since 2012 and as a direct result of the decline in popularity and the strong competition, further development and maintenance are very limited.
Existing Architecture
The following graphic shows our customer’s software architecture. For the sake of simplicity, certain components can be classified in frontend or backend logic.
All the data, which in turn originates from an internal customer of our customer, is fed into a Maria database, which is made accessible to the Java application via a Java Database Connectivity (JDBC) driver. Since the use of free strings can be considered error-prone and an Object-Relational Mapping (ORM) such as Hibernate is not compatible with the remaining part of the software architecture, a query builder is used to create SQL strings. By that, the developer’s input is validated through the support of the IDE (i.e. disallowing SQL statements containing syntax errors).
Pieces of Java code at runtime are managed within the confines of containers and process requests by accepting them and sending an appropriate response. This part is handled by the Tomcat server. Interfaces form the connection between frontend and backend. Components of the graphical user interface are still programmed in Java, but represent the first code that interacts directly with user input. Of course, input validation is more than necessary (for usability as well as security reasons). UI Code written by the developer in Java is then converted into JavaScript and HTML code by the use of the GWT Cross Compiler.
Furthermore, to allow multiple developers to work on the code as well as to reduce GWT test cases, GWT applications are generally based on the Model-view-presenter (MVP) architecture. Here, the model contains the business logic, while the view does not have any logic and does not know what data it is displaying, but only has layout information. The presenter acts as a link between the model and the view. In the image above, “UI Components” can be considered as the view, “Interfaces” as presenters and “Servlet Containers” maintained by the Tomcat server as models.
Related Migration Projects
Field reports on software migration projects containing GWT can be found in several scientific papers as well as on blogs and websites. In the following, some of them will be presented briefly along with the technical methodology that was used.
Migrating from GWT to Vue.js — FileCloud
- FileCloud has decided to replace an outdated GWT application with Vue.js. FileCloud primarily praises Vue.js for the user experience as well as developer-friendly support from numerous libraries and an active community. The migration process was done manually by analyzing and converting pieces of code from the old application.
Making the Move from GWT to AngularJS — Bandwidth
- Brian Dill from Bandwidth highlights customer complaints as the primary reason for a software migration from GWT to AngularJS. But also the time-consuming Java-to-JavaScript compilation is an important point as well as boilerplate code and the difficulties to integrate graphic elements since GWT manages CSS and HTML code in different formats. In this case, the migration process was also carried out manually.
Migrating from GWT to Angular.js — Berger-Levrault
- Berger-Levrault, a French software publisher, made a successful attempt to semi-automatically convert 8 GWT applications, each with more than 1.5 million lines of code and more than 400 web pages, into AngularJS applications. That very project can be considered to be pretty much the largest migration project involving GWT which is discussed in several scientific papers and blogs.
Apart from industrial use cases, of course, there are many other blog entries and articles (Integrating React with Google Web toolkit (GWT), How to integrate React into a Java legacy GWT client, Our journey from GWT to React) about integrating a more modern framework into existing GWT applications.
Our New Potential Architecture
So, what does that mean for us? In the current project phase, GWT not only affects the development due to the already mentioned flaws but also due to a new requirement that involves the use of graphic elements. There is hardly any useful tool out of the box for GWT, yet there are numerous JavaScript libraries. There is one quick fix for this. JavaScript code can be passed to the GWT compiler via comments in order to make them usable. This feature is implemented through the JavaScript Native Interface (JSNI) of GWT. See the below piece of code to get an idea. Note that Java methods are called within the JavaScript code again.
public class JSNIExample {
String myInstanceField;
static int myStaticField;
void instanceFoo(String s) {
// use s
}
static void staticFoo(String s) {
// use s
}
public native void bar(JSNIExample x, String s) /*-{
// Call instance method instanceFoo() on this
this.@com.google.gwt.examples.JSNIExample::instanceFoo(Ljava/lang/String;)(s);
// Call instance method instanceFoo() on x
x.@com.google.gwt.examples.JSNIExample::instanceFoo(Ljava/lang/String;)(s);
// Call static method staticFoo()
@com.google.gwt.examples.JSNIExample::staticFoo(Ljava/lang/String;)(s);
// Read instance field on this
var val = this.@com.google.gwt.examples.JSNIExample::myInstanceField;
// Write instance field on x
x.@com.google.gwt.examples.JSNIExample::myInstanceField = val + " and stuff";
// Read static field (no qualifier)
@com.google.gwt.examples.JSNIExample::myStaticField = val + " and stuff";
}-*/;
}However, the conglomerate of two programming languages makes the code quite illegible. Not to say dirty. Although this method is already practiced in isolated cases, a larger integrated library would represent a completely new dimension. It is even likely that JavaScript code would gradually make up the bulk of the (Java) application, given that external libraries containing functionalities that GWT cannot provide will continue to be required in the future. The figure below illustrates the architecture of such an application including external JavaScript code.
Arguably the most charming and comfortable approach would be to adopt the automated mechanism used in the project for Berger-Levrault as it seems well documented on GitHub and, of course, appears to be the most time-saving solution. However, initial tests have shown that the technologies used are not well documented, let alone self-explanatory. Regardless of that, the desirable outcome would still be to replace the existing client code with lightweight JavaScript code via one of the popular frameworks as can be seen in the figure below.
Note that the Tomcat server containing the business logic as well as the existing code may be retained in the backend, while the new framework would be based on top of it. This approach would still mean that two programming languages would be used in one application, but within logically separated blocks (frontend and backend). In addition, this solution saves converting many lines of Java code (roughly a quarter of the entire code of our application) during a potential migration process.
Conclusion
Web frameworks enjoy great popularity in simplifying the development of web applications. The big advantage of GWT at the beginning was that developers could concentrate completely on one programming language, namely Java, while the cross-compiler converted that code into standalone JavaScript files, which are highly optimized.
Whether a migration should ultimately be carried out should be agreed upon in close consultation with the customer, since such a project inevitably ties up resources that may be needed more urgently elsewhere. A possible compromise could be to create smaller prototypes alongside the ongoing development in order to be able to better assess the feasibility (in the case of a manual migration). Simplifying approaches such as low code no code could also be considered for this purpose.
Finally, a software migration is supposed to be about benefits for end users and not about the well-being of developers. But as already explained at the beginning, the potentially shortened build process and the associated faster delivery of new features as well as accelerated fixing of bugs already represent an immense advantage. Speeding up the development pace most probably represents the greatest advantage for end users as well as developers.
