Hi Scott! Thanks for speedy and seriously awesome response! :-)
Some questions inline. 2011/3/14 Scott Blum <sco...@google.com>: > On Mon, Mar 14, 2011 at 3:03 PM, Grzegorz Kossakowski > <grzegorz.kossakow...@gmail.com> wrote: >> >> 1. What's the difference between TypeMap and TypeOracle and why they >> seem to have overlapping functionality? > > In GWT, there are two major pieces of infrastructure that deal with > representing Java language input. > 1) A reflection of the user's type model for the purposes of running > generators. Approximately equivalent to the kind of information you can get > via Java reflection. Models types, fields, and methods, but not method > bodies. The entire machinery around this can be loosely referred to as > "TypeOracle", which is the primary interface for accessing this type model. > Generators use this type model to generate code. This infrastructure is > used in both dev mode and web mode, as Generators run in both contexts. So, if my GWT app doesn't have any generators exact contents of TypeOracle doesn't matter? I'm asking because I'm thinking of creating some stub data structures for jribble units and just move on to fixing some other issues and come back only once I want to support Generators written in Scala or Generators referring Scala. I'm asking because I don't want to create more problems than I solve at the time. > 2) The GWT AST, which is essentially a source-level representation of the > user's Java code, including method bodies, which is optimized and translated > into JavaScript. May be referred to as GWTC, the compiler, the web-mode > compiler, etc. Mostly lives in com.google.gwt.dev.jjs (which stands for > 'Java to JavaScript'). TypeMap is a small implementation detail that's only > useful for the JDT AST -> GWT AST translation. I see. It happens that TypeMap is quite interesting from my point of view because I'm translating Jribble AST to GWT AST by following JDT AST -> GWT AST translation (more or less). It's good to know that it's not being used anywhere else, though. >> >> 2. Why TypeOracleMediator operates on bytecode whereas gwtc is >> supposed to work with java source, or jdt's asts? > > Historically, we've run JDT twice. Once to build TypeOracle, and once to > build the GWT AST. Efforts have been made to transition TypeOracle to be > built from bytecode, which would eliminate one of these JDT runs in favor of > using external (presumably IDE-built) class files. I see. Thanks for clarification. >> >> 3. How emulation of object orientation is implemented in gwt? > > Using JavaScript prototype chains, and mangling method signatures such that > any given override of a method has a globally unique name in the compiled > output. Try compiling with -style PRETTY or DETAILED and inspect the > output. Is there one class that is dealing specifically with emulating object orientation or it's scattered around many classes? I'm asking because toString() call get's translated to toString_2() javascript call and this method is not being defined anywhere in js source code. I'm trying to pinpoint location where this stuff is handled to understand why I get a call to non-existing place. >> >> 4. What are main phases in gwtc's execution. What are dependencies? > > JavaToJavaScriptCompiler .precompile() is what I would consider the main > high-level algorithm. But here's a text overview. > 1) Build TypeOracle from the initial set of available source units > (CompilationStateBuilder). > 2) Begin running the web mode compile (WebModeCompilerFrontEnd). > 3) As the web mode compile runs, we encounter GWT.create() calls > (FindDeferredBindingSitesVisitor). > 4) Use the rebind infrastructure to resolve rebind requests. This may > entail running Generators, which generate new code. > 5) Newly-generated types get added to CompilationState + TypeOracle in a bit > of a loop-back process. > 6) Newly-generated types may themselves contain GWT.create() calls, looping > back through step 4. > 7) Eventually, all our code is generated. Get rid of TypeOracle, we don't > need it anymore. > 8) GenerateJavaAST turns the JDT AST into the GWT AST. > 9) Normalize certain difficult constructs. > 10) Optimize. > 11) Post-optimization normalizes to turn high-level Java constructs into > JS-specific implementation details (but still Java AST). > 12) GenerateJavaScriptAST > 13) Optimize JS AST > 14) Produce JS source text. That looks great. Thanks! >> >> Do you guys have anything (slides, blog posts, discussions, etc.) that >> would help me to better understand those matters? > > Here's wiki entries for TypeOracle / CompilationState. The first is > outdated by useful to understand the second one. > http://code.google.com/p/google-web-toolkit/wiki/CompilationUnit_1_5 > http://code.google.com/p/google-web-toolkit/wiki/CompilationUnit Thanks. This helps to understand another bit of GWT's architecture. I've got another question. Do you have any tool for checking correctness of GWT's ASTs or a tool that allows one to dump ASTs and compare them? The scenario I have in mind is like this: 1. I have minimal jribble example that exhibits some obscure problem like with toString described above and I fail to find a bug but I suspect that GWT ASTs I get out of Jribble are broken. 2. I prepare corresponding Java code that imitate code from jribble. This should work (or I found a bug in gwtc itself but this is highly unlikely). Now I'd like to compare those two ASTs. Such comparison should immediately reveal the source of my problems. Do you have anything handy that would help me with this or do you have some other idea how to solve my problem? -- Best regards, Grzegorz Kossakowski -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
