Desktop Java

Quick Tip: Debugging a GWT application using Chrome Dev tools

Debugging is an important aspect of software development. Having the right tools can save a lot of time and headaches. Before GWT Super Dev mode, the classic Dev mode allowed to use JVM debugging. Developers could set break points within their IDE and use debug mode to track bugs and errors. Now with the Super dev mode, things are different. The whole application is compiled and run within the browser, so using JVM debugging is not possible anymore. The question that comes to mind is: is it possible to debug Java in the browser ? luckily the answer is yes.
In principle, browsers can only run and debug javascript. To overcome this shortcoming, source maps were introduced. Source maps serve as a blue print for mapping from a source to a target language. Source maps can be used for a variety of languages and even to map between minified and unminified javascript. In this post, we are going to use source maps and Chrome dev tools to debug our application error. We will use the polymer-starter-kit, which suffers from a run time error, as an example. The error is the following

This error does not break the app, but it is important to know what causes it.

Without source maps:

If we try going to the sources without enabling source maps, we would not be enable to tell where the error is happening in our source code.

Enabling source maps:

To overcome this, we need to activate source maps. Source maps can be activated on Chrome by going to settings -> Sources -> Enable JavaScript source maps. Normally source maps are generated by default by the GWT compiler. In case they are not, setting the following property in the .gwt.xml can active them:

After enabling breakpoints we can see that the error now points to the .java file and not the .js file:

Setting a break point:

Now that we see where the error happens, we can set a breakpoint to inspect the state of the application. The breakpoint can be simply set by clicking on the line number in the editor.

Tracking the error:

Finally, we can refresh the application. The application will stop when it reaches the breakpoint. We can then inspect the call stack and the variables values.

Now that we know were the error happens exactly in our code. We can check if we misused a statement. In this case, removing this line, which was useless, was enough.

Using Chrome workspace (Optional)

Chrome workspaces allows mapping files loaded by the browser to files on disk and making changes directly to files from Chrome. This can be useful if you do not need IDE assistance, and do not want go back and forth from the browser to the IDE. To make use of Chrome workspace, you can right click on and empty spot on the Sources Tab on the left and click on “add folder to workspace”. Then, you can right click on the opened file, and click on “map to file system resource”. More on that can found at:


Debugging GWT apps in the browser using source maps can save a lot of time, and help track errors properly. Chrome Dev tool offers a powerful debugging tool that can help increase productivity and quickly resolve bugs. More advanced debugging features are offered by the Chrome Dev tool such as debugging HTTP requests and DOM changes, if you would like to explore those, you can go to Google’s user guide:

Worth watching : DevTools: State of the Union 2017 (Google I/O ’17)

Zakaria Amine

Zakaria is a freelance software engineer who enjoys working with Java web frameworks, and microservice architectures. During his free time, Zakaria works on hobby projects, and blogs about his favorite topics like GWT and Spring.
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
Back to top button