Please don't repeat GWT's mistake!

[Amir Michail]

Hi,

Please support Java byte code so that we can use any languages that
work using the JVM such as Scala.

GWT made a mistake in only supporting Java. I hope they correct it.

Amir

[Peter Recore]

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. Part of GWT's appeal
is that the end product is fast and lean javascript. While it would
be nice if GWT could turn random x86 executable into blazingly fast
javascript, I'm not going to criticize the GWT team because they
haven't done so yet. If I'm wrong, and making GWT work with JVM is
trivial to do, that's awesome! Submit the patch to the GWT team. The
fact that no one has yet done so yet implies to me that this is not an
easy thing to do, or else no one really wants to do it. In either
case, it is not a mistake that it hasn't been done.

If you really like working in Scala, you could look into contributing
to the project to compile Scala into Java, mentioned at the bottom of
this page: http://www.scala-lang.org/faq/4

If this post has a slightly sharp tone, it's because I don't like it
when people criticize open source projects with vague complaints while
at the same time asking for new features.

-peter

[Amir Michail]

On Tue, Oct 21, 2008 at 3:59 PM, Peter Recore <peter...@gmail.com> 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. Part of GWT's appeal
> is that the end product is fast and lean javascript. While it would
> be nice if GWT could turn random x86 executable into blazingly fast
> javascript, I'm not going to criticize the GWT team because they
> haven't done so yet. If I'm wrong, and making GWT work with JVM is
> trivial to do, that's awesome! Submit the patch to the GWT team. The
> fact that no one has yet done so yet implies to me that this is not an
> easy thing to do, or else no one really wants to do it. In either
> case, it is not a mistake that it hasn't been done.
>
> If you really like working in Scala, you could look into contributing
> to the project to compile Scala into Java, mentioned at the bottom of
> this page: http://www.scala-lang.org/faq/4
>
> If this post has a slightly sharp tone, it's because I don't like it
> when people criticize open source projects with vague complaints while
> at the same time asking for new features.

I don't mind criticism when I say something that is incorrect.
However, I don't believe that it is the case here.

Also, GWT isn't just an open source project. It's an open source
project where code is written mostly by Google employees.

Amir

>
> -peter
>
> On Oct 21, 2:07 pm, Amir Michail <amich...@gmail.com> wrote:
>> Hi,
>>
>> Please support Java byte code so that we can use any languages that
>> work using the JVM such as Scala.
>>
>> GWT made a mistake in only supporting Java. I hope they correct it.
>>
>> Amir
> >
>

--
http://chatbotgame.com
http://numbrosia.com
http://twitter.com/amichail

[Sal]

I have to agree. In fact, I would say that there was no mistake at
all.

[Sumit Chandel]

Hello everyone,

Sumit Chandel from the GWT team here.

I just wanted to clarify a couple of inaccuracies I've observed in
this thread.

Firstly, I don't believe that the choice to work from Java source
instead of JVM bytecode was a bad decision. The team chose to work
from Java source for all the reasons that Peter described above. For
what GWT is trying to do, which is to produce highly optimized and
lean JavaScript, it would be nonsensical to work from already
optimized JVM bytecode and then attempt to reverse engineer the
bytecode to then be able to infer enough information for optimization
and then translate to JavaScript.

Secondly, GWT is indeed an open source project that is being developed
and maintained by a team of Google engineers. However, the team
accepts hundreds of patches between releases that are contributed from
the open source community. Compiler optimizations and bi-directional
support for widgets in GWT 1.5 are examples of that. Also, we've had a
number of successful open source developers take GWT and build their
own open source projects from it, such as GWT-Ext, hibernate4gwt and
so on.

That said, it would be awesome to see a group of open source
developers take on the challenge of generating highly-optimized
JavaScript from the bytecode level, or even from source in another
programming language. Also, if someone were to get a nice proof-of-
concept working, the team would love to discuss it on the GWT
Contributors forum and see where / how we could roll the idea and help
with the effort if the community starts gaining interest.

GWT Contributor Forum:
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Cheers,
-Sumit Chandel

[Amir Michail]

On Oct 24, 12:46 pm, Sumit Chandel <sumitchan...@google.com> wrote:
> Hello everyone,
>
> Sumit Chandel from the GWT team here.
>
> I just wanted to clarify a couple of inaccuracies I've observed in
> this thread.
>
> Firstly, I don't believe that the choice to work from Java source
> instead of JVM bytecode was a bad decision. The team chose to work
> from Java source for all the reasons that Peter described above. For
> what GWT is trying to do, which is to produce highly optimized and
> lean JavaScript, it would be nonsensical to work from already
> optimized JVM bytecode and then attempt to reverse engineer the
> bytecode to then be able to infer enough information for optimization
> and then translate to JavaScript.

Can't some of this optimization be done by the javascript JIT?

Amir

[Peter Recore]

> Can't some of this optimization be done by the javascript JIT?
>
> Amir

This would be less than optimal for 2 reasons - first, you would be
sending much bigger javascript files than you might need to be, which
is bad for response times. Second, not all javascript JIT's are
created equal, and the more optimization we can do ahead of time the
better. This is probably a discussion better suited to the GWT group
though.

[Lex Spoon]

On Oct 21, 3:59 pm, Peter Recore <peterrec...@gmail.com> 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

[Toby Reyelts]

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.

[Amir Michail]

On Mon, Oct 27, 2008 at 1:59 PM, Toby Reyelts <to...@google.com> wrote:
>
> 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.

Given that Scala is vastly better than Java and is quite stable, is
there any particular reason why Google doesn't use Scala for its own
development?

Amir

--