I'm mostly in agreement with Lex here. Bytecode isn't a "highly- optimized" format. In fact, most Java compilers do almost no optimizations on the bytecode they generate. This makes the job of "understanding the code" easier on the JIT. I think this is fairly self-apparent when you recognize that Java decompilers are awfully good at reconstructing Java programs from bytecode.
So, it's not really bytecode that prevents GWT from supporting other languages. Rather, it's that most other languages posited for GWT rely on dynamic features of the JVM - i.e. reflection and dynamic class loading. For example, Groovy, JRuby, and Jython all make heavy use of these features. GWT avoids these features, because they are not readily optimizable in the environment of a JavaScript application. Scala's a great counter-example to this - Most of the libraries and core features of Scala aren't dependent upon dynamic class loading and reflection. In my opinion, it's imminently feasible to have GWT Scala applications. We're certainly willing to review patches. On Oct 25, 2:33 pm, Lex Spoon <[EMAIL PROTECTED]> wrote: > On Oct 21, 3:59 pm, Peter Recore <[EMAIL PROTECTED]> wrote: > > > I don't think "mistake" is the right word there. I'm not an expert on > > Java Compilers and JVMs, but I'll go out on a limb here and risk > > embarrassing myself - my gut feeling is that Java is much easier to > > compile into javascript than random bytecode is. GWT makes aggressive > > optimizations based on information it can infer from java semantics. > > If GWT had to generalize to work with any possible bytecode, I doubt > > the resulting javascript could be as efficient. > > I work on the GWT compiler, and I agree with your conclusion but not > with the reason. The issue is more the combination of: > > - the output format is an expression language with general nesting, > while bytecode is more like a three-address intermediate > representation (IR) > - current JS vm's have terrible optimization, though that is changing > - output size is very important for GWT, which isn't changing > > It would be bad to emit code that looks like this: > > var t1, t2, t3; > t1 = bar; > t2 = foo(t1); > t3 = baz; > return t2 + t3; > > You really want to emit this, instead, which is both shorter and, on a > non-optimizing JS VM, faster: > > return foo(bar) + baz; > > If GWT took bytecode as input, then it would need to be able to > transform code that looks like the former into code that looks like > the latter. This has advantages other than being able to take > bytecode as input, so it might be worth looking into. However, it > would take a significant amount of work -- a man-month perhaps -- to > add this transformation to the compiler, and thus far there have > always been competing features that seem more important. > > The reason given so far in this thread is that bytecode would be bad > for optimization. That's actually the opposite of the truth. A > bytecode-like three-address IR would be really convenient for > optimization, because it makes the control flow explicit. With the > current tree-like IR, the compiler's optimizers have to do some really > tricky reasoning about control flow around an expression. Just look > at the two examples above. In the first example, control flows from > the first statement to the last, one after the other. In the second, > control flow hops all over the place, forward and backward. > > By the way, for Scala in particular, I don't think going through > bytecode is the best way. It would be better to work out a new > intermediate format that is like Java source, but that does not have > the silly restrictions that Java has that GWT does not need. For > example, that intermediate format should have an equivalent to multi- > expressions (that is, C's or JavaScript's comma operator, or Scala's > block expressions). Scala could easily generate it, and GWT could > easily take it as input. Such a format might be useful for other > projects, too. It would have the flexibility of bytecode while > retaining nested expressions. > > Lex Spoon > > PS -- I'm not in this group; I was simply pointed at the thread --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
