GWT suitable as a general purpose Java to JavaScript translator?

[Jeff Wu]

We have some Java programs that we would like to translate to JavaScript.  These Java programs were not written with the GWT UI libraries, but with our own bitmap manipulation libraries.  Would GWT be a suitable tool to do this translation?  We are looking at GWT to get us there 50%, and we'll have to re-implement the bitmap libraries in something like pixijs.

Would GWT work for us?  Would the resulting JavaScript be readable/understandable for continuing development on it (we would run the translator once and then use the GWT JavaScript as the base from then on).

[Kirill Prazdnikov]

If your code is portable pure java code - no problem.

As a possible performance issue is that float or byte GWT array is an array of JsObjets (JsNumbers).

[Michael Zhou]

Having done that myself, my guess is that it's suitable, and can probably get you more than 50%. It depends on how many external libraries you use (eg. Google Gson is not GWT-compatible because the use of reflection, and fortunately most of Guava is GWT-compatible) and how many JRE classes / methods you use that are not emulated by GWT (yet) (eg. java.io.File is not emulated). The list of currently supported JRE emulations is at: http://www.gwtproject.org/doc/latest/RefJreEmulation.html.

Several techniques I used when I compiled Google Closure Compiler (https://github.com/google/closure-compiler), a large Java application with 210K lines of code, as a pure JavaScript library with GWT:

1. Use @GwtIncompatible annotations on classes that are not needed / don't make sense in a JavaScript environment, like ones that use java.io.File heavily. I recommend using the one provided by Guava: http://google.github.io/guava/releases/snapshot/api/docs/com/google/common/annotations/GwtIncompatible.html, so that your code won't have an explicit dependency (import statement) on gwt-dev.jar. The GWT compiler ignores any class or method annotated with @GwtIncompatible.

2. If a particular method has to be marked @GwtIncompatible but is called by a GWT-compatible method, you might try factoring it out into a utility class and super-source the utility class (see point 3).

3. Use super-source (search for <super-source> in http://www.gwtproject.org/doc/latest/DevGuideOrganizingProjects.html). super-source is handy when you want to provide a replacement implementation for the GWT-compiled version of your application. For example, a class that manipulates bit often can be super-sourced and re-written with JSNI / JsInterop. If it's not intended to be supported in the GWT-compiled version, it can simply be a no-op replacement. Closure Compiler's repository contains many examples of super-sources, see https://github.com/google/closure-compiler/tree/master/src/com/google/javascript/jscomp/gwt/super.

I'm not 100% certain, but these techniques should still apply to J2CL (Jackal, the new Java-to-JavaScript transpiler that might serve as the core in GWT 3.0). JSNI might not be supported though so you should better go with JsInterop.

Good luck!