GWT
From APIDesign
(New page: GWT is a Java port that runs in a browser. The GWT compiler translates Java code to JavaScript.) |
|||
| Line 1: | Line 1: | ||
| - | [[wikipedia:Google_Web_Toolkit|GWT]] is a [[Java]] port that runs in a browser. The [[GWT]] compiler translates [[Java]] code to [[JavaScript]]. | + | [[wikipedia:Google_Web_Toolkit|GWT]] is a [[Java]] port that runs in a browser, but (unlike [[Bck2Brwsr]] project) compiles on the desktop. The [[GWT]] compiler runs in real [[VM]]] (e.g. [[HotSpot]]) and translates [[Java]] code to static [[JavaScript]]. As such the [[GWT]] looses a lot of the dynamism [[Java]] could offer - late bindings of classes and libraries, generating [[bytecode]] on the fly, loading new classes, using reflection, etc. is hard/almost impossible in [[GWT]]. |
| + | |||
| + | === Slow [[JavaScript]] Interpreters and Doing Less Work === | ||
| + | |||
| + | [[GWT]] was the first attempt to bring [[Java]] to browser. At the time of its introduction, the [[JavaScript]] interpreters in browsers were slow and it made sense to do as much work as possible in advance. However since then the speed of [[JavaScript]] increased enormously and as such it becomes more and more viable to bring more of [[Java]] [[Bck2Brwsr]]. | ||
| + | |||
| + | For example the [[Bck2Brwsr]] project does not deal with [[Java]] source, but with [[Java]] [[ByteCode]]: | ||
| + | * one does not need to write lexer and understand [[Java]] keywords | ||
| + | * one does not need to write parser to for a [[Java]] [[AST]] | ||
| + | * one does not need to do attribution - e.g. resolve the fully qualified name of each symbol | ||
| + | All of this has already been done by [[JavaC]] when generating the [[ByteCode]]. [[Bck2Brwsr]] can use such information, become more effective and at the end fit into the browser. | ||
Revision as of 20:09, 21 March 2013
GWT is a Java port that runs in a browser, but (unlike Bck2Brwsr project) compiles on the desktop. The GWT compiler runs in real VM] (e.g. HotSpot) and translates Java code to static JavaScript. As such the GWT looses a lot of the dynamism Java could offer - late bindings of classes and libraries, generating bytecode on the fly, loading new classes, using reflection, etc. is hard/almost impossible in GWT.
Slow JavaScript Interpreters and Doing Less Work
GWT was the first attempt to bring Java to browser. At the time of its introduction, the JavaScript interpreters in browsers were slow and it made sense to do as much work as possible in advance. However since then the speed of JavaScript increased enormously and as such it becomes more and more viable to bring more of Java Bck2Brwsr.
For example the Bck2Brwsr project does not deal with Java source, but with Java ByteCode:
- one does not need to write lexer and understand Java keywords
- one does not need to write parser to for a Java AST
- one does not need to do attribution - e.g. resolve the fully qualified name of each symbol
All of this has already been done by JavaC when generating the ByteCode. Bck2Brwsr can use such information, become more effective and at the end fit into the browser.
Follow
