why not use bytecode?

[rjcarr]

I'm not an expert in bytecode or the JVM, and I'm sure this has been
asked before, but I'm wondering why GWT is a source-to-source
translation and not a bytecode-to-source translation?

Is the bytecode not expressive enough? Is it too hard to decompile?
It seems to me it would have been worth the extra effort to translate
from bytecode, but maybe it simply isn't possible?

[Ian Petersen]

There has been some discussion of this in the past, perhaps on the dev
mailing list, so you might want to search for it to see if that
answers your questions more fully.

I forget the argument, but I think it came down to expressiveness.
Well, not expressiveness, but something to do with clarity. I think
it's easier to optimize Java source than bytecodes because the source
has more semantic information, or something like that. As for the
ease of decompilation, I don't think that's the problem. My
understanding is that Java is particularly easy to decompile, but I
don't know why it's the case.

Why does it seem to you that bytecodes-to-source translation is "worth
the extra effort"? What use case does that enable that
source-to-source doesn't enable (besides using binary-only libraries,
because that's probably not as useful as you might think--GWT
libraries need to be written with GWT in mind, usually)?

Ian

--
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com

[rjcarr]

Thanks for the response. Here's my (likely unqualified) response:

> Why does it seem to you that bytecodes-to-source translation is "worth
> the extra effort"?

First thing that comes to mind is language independence. I'm pretty
sure that GWT1.5 is now supporting Java 1.5 features, but it is my
understanding that the bytecode is relatively stable. I'm sure there
was a lot of effort that went into GWT 1.5 that could have been
avoided by using bytecode. And we might do this all over again for
Java 1.7 and then for 2.0. Had bytecode been the target from the
start, there wouldn't be this problem, and then other languages could
have been supported as well: groovy, scala, jruby, jython, etc.

> What use case does that enable that
> source-to-source doesn't enable (besides using binary-only libraries,
> because that's probably not as useful as you might think--GWT
> libraries need to be written with GWT in mind, usually)?

Umm ... I think this does matter. I haven't thought about this too
much, but it seems that if a module is translated from bytecode then
it wouldn't need to be re-translated every single time from scratch.
I could be wrong about this one, I'm not sure. I'll have to think
more about it. :)

[Magno Machado]

What about generics?

AFAIK, the generic types information can be used to improve the optimization on generated JS. (Someone please tell me if I'm wrong)
However, as there are no generic types at bytecode level (thanks, type erasure...), we would not take advantage on it.

 

2008/5/13 rjcarr <rjc...@gmail.com>:

[Axel Kittenberger]

> Why does it seem to you that bytecodes-to-source translation is "worth
> the extra effort"? What use case does that enable that
> source-to-source doesn't enable

Use of other languages that can compile to javabyte code. Like xruby.

If one could use xruby with gwt to generate javascript, this would be
really cool...

[Ping]

I'm guessing that it's easier to translate Java to JavaScript because
many concepts are 1-1 mapping or even 1-N mapping (since JS is more
expressive you end up having several ways to implement, for example,
inheritance). If the translation were to be done at the bytecode
level, the GWT folks would end up implementing a javascript runtime
for java and surely would loose many optimizations. Java being a
static language gives you many benefits over more dynamic languages in
respect to optimizations. But surely I think a bytecode to js compiler
would be extremely interesting... Although some problemes arise such
as JSNI (where would you read the jsni code from?)

[Axel Kittenberger]

Also people "underestimate" the bytecode style of java, and consider
it some sort of condensed code. Its not so. The java bytecode is for
the java virtual machine, which is actually very like a real CPU, that
is has a Stack for example... I guess this is rather difficult and
cumbersome to implement in javascript, instead of implementing the
direct source equivalent...

Still I found once rubyx and thought, "cool now I can put this
together to the """Ruby Web Toolkit""", but not so. since rubyx
generates bytecode, and GWT wants source... :-(

[stuckagain]

Hey,

A good question... some potential reasons that I can think off:

I guess in GWT 1.4 the reason for using source code is because they
were using javadocs for serialisation information (@gwt.typeArgs).

In GWT 1.5 generics would be a impossible to optimize since they are
erased by the compiler.
JVM byte code hide a lot of information, not just generics but also
optimized for loops.
try {} catch{} finally{} blocks are also hard to detect in JVM byte
code. I have not yet found a Java
decompiler that can manage the decompilation of complex exception
handling code.


David

> > more about it. :)- Hide quoted text -
>
> - Show quoted text -

[pohl]

JSNI is a big one. Look at an example JSNI method. This one
opens a URL in a new browser window:

private static native JavaScriptObject open(String url, String
name, String features) /*-{
return $wnd.open(url, name, features);
}-*/;

Notice both the elegant co-option/abuse of the "native" keyword
(normally intended
for JNI and the funky comment that allows you to include arbitrary
JavaScript right
in the Java source code.

A bytecode-->JavaScript compiler would need a replacement for this
mechanism
that allows you to

1) embed JavaScript source in your Java source...
2) ...in such a way that javac won't puke on...
3) ...and in such a way that javac won't discard...

...and, hopefully, in a way that is as clear & readable as the current
mechanism,
which is brilliant in terms of clarity.

[jhulford]

Not that I'd like this better than the current JSNI way of doing
things, but you could write the compiler so you put your native
javascript in a .js file and have the compiler look for it in there.
Basically, like how the actual JVM looks for .so or .dll files in its
library path when standard native methods are used.

Again, I wouldn't suggest doing that, just saying compiling from
bytecode probably doesn't need to preclude JSNI functionality.

[jlw]

> Why does it seem to you that bytecodes-to-source translation is "worth
> the extra effort"? What use case does that enable that
> source-to-source doesn't enable (besides using binary-only libraries,
> because that's probably not as useful as you might think--GWT
> libraries need to be written with GWT in mind, usually)?

Compiling from bytecode could also allow one to use AOP on your GWT
GUI. Currently, all of the AOP toolkits I know of work off of
bytecode. I can think of several cases where this would be very
valuable.

Having said that, I'm still not certain that compiling from bytecode
is worth it. You would lose so much of the original language. Bytecode
is really a virtual assembly language--which has barely any
expression--and Javascript is an expressive language. It would be very
difficult to compile bytecode to Javascript and get the level of
performance GWT already provides. IMHO

[Olivier Monaco]

Hi,

> There has been some discussion of this in the past, perhaps on the dev
> mailing list, so you might want to search for it to see if that
> answers your questions more fully.

http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/edc4151c015566b7/45c381caceec4ab0

Olivier.

[Axel Kittenberger]

2 Things I would like to add...

1) What about the idea for the intermediate solution to just use a
java decompiler, to generate .java files from .class files, and then
run GWT over the java files? This should run well for the original
poster, and might even get to work with xruby.

2) Due to missing knowledge I cannot state a good opinion about the
advantages from GWT-compiling from source or from bytecode. However
the JSNI that is so often cited in this discussion is a non issue to
me. If you want embeded JSNI Just run once over the source once with
the compiler, and generate a "javascript native library".. then
compile this with the bytecode to the endproduct:

It would look like: .JAVA ---> "GWT JSNI Compiler" ---> Native
Libarary ----\
}--
GWT compiler ----> Together .js output
.JAVA --->javac -----> .class data
----------------------/

On May 15, 10:31 pm, Olivier Monaco <olivier.mon...@free.fr> wrote:
> Hi,
>
> > There has been some discussion of this in the past, perhaps on the dev
> > mailing list, so you might want to search for it to see if that
> > answers your questions more fully.
>

> http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse...
>
> Olivier.

[Axel Kittenberger]

A: .java --"GWT JSNI Compiler"-> "JavascriptNativeLib"
B: .java --javac--> .class data
--------------------------------------
C: "JavascriptNativeLib" + javac --GWT compiler _> .js output

Okay that graph went wrong, 2nd try.

[Olivier Monaco]

Hi,

On 17 mai, 14:26, Axel Kittenberger <axe...@gmail.com> wrote:
> 1) What about the idea for the intermediate solution to just use a
> java decompiler, to generate .java files from .class files, and then
> run GWT over the java files? This should run well for the original
> poster, and might even get to work with xruby.

You can do it right now...

> 2) Due to missing knowledge I cannot state a good opinion about the
> advantages from GWT-compiling from source or from bytecode. However
> the JSNI that is so often cited in this discussion is a non issue to
> me. If you want embeded JSNI Just run once over the source once with
> the compiler, and generate a "javascript native library".. then
> compile this with the bytecode to the endproduct:

GWT compilation "takes a while". Adding one more pass (source to
bytecode to JS) can increase compilation time. So, if you add a
"source JSNI to JS) pass, imagine the time to compile...

Nobody wrote about Deferred Binding. How to manage Deferred Binding
when compiling from bytecode ? Generator has to produce bytecode? or
GWT has to call javac for each generated class (good for compile
time!!!)?

Olivier.

[Axel Kittenberger]

I don't think defered binding would be affected by this, would it?
Since the compiler could still chose which bytecode version to take...

I know the decompiler approach works right now. (@hint at original
poster ;-) Would be an interesting experiment how 1) "classic java
compile" with optimization turned on 2) decompile 3) GWT compile,
affects performance/size of code. Unfortunally have no time right now,
I looked a bit into java decompilers, but this is a huge mess :
( (either non-free, or packed with GUI, or created in some OS
dependend non-java environment, etc. None of those I looked at I would
consider good, so this needs a hack on this end too, taking a
OpenSourced decompiler and turn it into something usefull..)

[pixelh...@gmail.com]

There are many online decompilers. The big problem I see is that in most cases I don't want my code decompiled. The entire purpose of this instead of HTML5 is so that my code cannot be reproduced unless I open source it.

Also, if someone really wants a bytecode to js compiler, they can make one. I for one think that GWT is extremely helpful as is.