Java-Javascript compiler

519 views
Skip to first unread message

Tali

unread,
Oct 2, 2006, 1:22:34 PM10/2/06
to Google Web Toolkit
Hi,

I would like to compile my java code tointo javascript.

I tried using GWT but the resulting javascript doesnt look nice (even
in "pretty" mode).

The main problem is that it looses the connection between the objects
and the functions - the functions do not belong to the object or to its
prototype.

Any idea how I can achieve a more OO connection between the java and
javascript code?


Thanks , Tali

mP

unread,
Oct 2, 2006, 6:28:26 PM10/2/06
to Google Web Toolkit
I think your complaining about the fact that the this context is passed
as the first argument in each function call. This was probably done to
ensure the correct context is used in all cases.

The generated javascript in pretty mode is quite readable. GWT supports
all the java / oo constructs such as polymorphism etc so why the
complaint ?

I believe that GWT does modify the String object's prototype.

ash

unread,
Oct 2, 2006, 7:40:44 PM10/2/06
to Google Web Toolkit
tali,

> I would like to compile my java code tointo javascript.

i too was once on the same mission and probably had similar
expectations to you.


> I tried using GWT but the resulting javascript doesnt look nice (even
> in "pretty" mode).

having it look pretty is the least of the problems.


> The main problem is that it looses the connection between the objects
> and the functions - the functions do not belong to the object or to its
> prototype.

the approach taken my the gwt compiler reminds of the translation of
eiffel to C that i used moons ago. that is, it seemed to have flattened
everything in its rendering.


> Any idea how I can achieve a more OO connection between the java and
> javascript code?

i once had a vision of fusing java2script[1] (aka. pacemaker/j2s) and
gwt together so that i could leverage reflection and swt widgets, but
these two technologies are orthogonal.

to save you a j2s investigation i have coded a sample for you to
analyse the translation:

1. bootstrap
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>org.javaongems.j2s.test.Rectangle</title>
<script type="text/javascript"
src="../../tool/eclipse-3.2/plugins/net.sf.j2s.lib_1.0.0/j2slib/j2slib.z.js"></script>

</head>
<body>
<script type="text/javascript">
ClazzLoader.packageClasspath ("java",
"../../tool/eclipse-3.2/plugins/net.sf.j2s.lib_1.0.0/j2slib/", true);
ClazzLoader.packageClasspath ("org.eclipse.swt",
"../../tool/eclipse-3.2/plugins/net.sf.j2s.lib_1.0.0/j2slib/", true);
ClazzLoader.setPrimaryFolder ("bin");
ClazzLoader.packageClasspath ("org.javaongems.j2s.test", "bin/");
ClazzLoader.loadClass ("org.javaongems.j2s.test.Rectangle", function ()
{
org.javaongems.j2s.test.Rectangle.main([]);
});
</script>
</body>
</html>


2. Java code
package org.javaongems.j2s.test;

public class Rectangle {
public int x, y;
public int width, height;

public void moveBy(int deltaX, int deltaY) {
x += deltaX;
y += deltaY;
}

public String toString() {
return "[" + x + "," + y + "," + width + "," + height + "]";
}

static public void main(String[] args) throws IllegalArgumentException
{
if (args.length > 0)
throw new IllegalArgumentException("sample does not accept input
params");
Rectangle app = new Rectangle();
for (int i = 0, j = 0; i < 10; i++, j++) {
app.moveBy(i, j);
System.out.println("loc: " + app);
}
}

static {
System.out.println("loading Rectangle");
}

static private class StaticNested {
}

private class Nested {
}
}

3. j2c code
Clazz.declarePackage ("org.javaongems.j2s.test");
Clazz.load (null, "org.javaongems.j2s.test.Rectangle",
["java.lang.IllegalArgumentException"], function () {
c$ = Clazz.decorateAsClass (function () {
this.x = 0;
this.y = 0;
this.width = 0;
this.height = 0;
if (!Clazz.isClassDefined ("org.javaongems.j2s.test.Rectangle.Nested"))
{
Clazz.pu$h ();
c$ = Clazz.decorateAsClass (function () {
Clazz.prepareCallback (this, arguments);
Clazz.instantialize (this, arguments);
}, org.javaongems.j2s.test.Rectangle, "Nested");
c$ = Clazz.p0p ();
}
Clazz.instantialize (this, arguments);
}, org.javaongems.j2s.test, "Rectangle");
Clazz.pu$h ();
c$ = Clazz.declareType (org.javaongems.j2s.test.Rectangle,
"StaticNested");
c$ = Clazz.p0p ();
Clazz.defineMethod (c$, "moveBy",
function (deltaX, deltaY) {
this.x += deltaX;
this.y += deltaY;
}, "~N,~N");
Clazz.overrideMethod (c$, "toString",
function () {
return "[" + this.x + "," + this.y + "," + this.width + "," +
this.height + "]";
});
c$.main = Clazz.defineMethod (c$, "main",
function (args) {
if (args.length > 0) throw new IllegalArgumentException ("sample does
not accept input params");
var app = new org.javaongems.j2s.test.Rectangle ();
for (var i = 0, j = 0; i < 10; i++, j++) {
app.moveBy (i, j);
System.out.println ("loc: " + app);
}
}, "~A");
{
System.out.println ("loading Rectangle");
}});


---

imho, there is a lot to like about what j2s does and how it does it.

when the gwt team gets around to looking at how to address large
applications and dynamic module loading we may see a low level
architectural change in script generation. although, i suspect this is
some time away.

both gwt and j2s use java source as their input. there is another very
interesting project named xml11[2] which uses java byte code as the
input and can send xmlvm[3] instruction sets which eventually gets
rendered as javascript.

there are so many great technologists out there that are severley under
resourced. i can only hope that the google open-source team can sponsor
some of these guys and then consider leveraging concepts into gwt.

good luck
rgds ash
http://www.gworks.com.au


1 - http://j2s.sourceforge.net/
2 - http://www.xml11.org/
3 - http://www.xml11.org/xmlvm/

mP

unread,
Oct 2, 2006, 9:35:06 PM10/2/06
to Google Web Toolkit
The >this< argument in javascript doesnt always point to the object
itself which is a pain and the reason the something like
function.apply() exists.

In the end who cares what or how the javascript looks like as long as
it faithfully emulates java.

fwiw.

mP

br...@google.com

unread,
Oct 3, 2006, 9:29:53 AM10/3/06
to Google Web Toolkit
I can tell you the motivation behind GWT's code generation: to be as
small and as efficient as possible :-)

A few interesting specifics...

- We do explicitly remove polymorphism as much as possible. Calls that
are polymorphic at runtime take longer to dispatch and require extra
code to set up. So, we do whole program analysis to turn polymorphic
calls into static ones wherever possible.

- Static calls can often be inlined, which can be a big win for simple
methods.

- Even if we don't inline, knowing exactly which method is being called
statically allows the compiler to discard more code. For example, what
if a superclass method is always overidden, so that the superclass
method could never be called? The compiler can identify this and
completely remove the method in the superclass. That alone saves code,
and even better, may cause several other classes not to be instantiated
(e.g. locals in the superclass method), which increases the odds that
an entire class may be able to be discarded. And so on, recursively...

- This one's funny. When you turn an instance method into a static
one, you have to explicitly pass in 'this', right? Well, 'this' is a
keyword that cannot be obfuscated, yet it's used a lot. Making
functions static has this weird and great size benefit: you can
obfuscate the explicit 'this' (since it's just a parameter), which
reduces code size due to fewer uses of the 'this' keyword.

It wouldn't necessarily be a big deal to turn off these optimizations
so that the generated JavaScript can look prettier, more like it was
handwritten. But that actually defeats the big-picture point: the
benefit of compiling is that *your* source looks nice (Java) and the
object code is very efficient (JavaScript). When's the last time you
thought about the readability of the binary produced by your C
compiler?

But...all that said, it is important for people to be able to
understand what's going on in the output, so that they feel comfortable
with the translation process. That's why we added PRETTY and DETAILED.
However, if there's enough demand, maybe we could add a
"-slowerBiggerPrettier" compiler flag :-) I'm kidding, of course.
Please comment if you disagree with my point of view or if there's some
important use case we're not thinking about.

-- Bruce

claude

unread,
Oct 3, 2006, 10:20:53 AM10/3/06
to Google Web Toolkit

br...@google.com wrote:
> - This one's funny. When you turn an instance method into a static
> one, you have to explicitly pass in 'this', right? Well...

LOL. I just can't get enough of these. Keep 'em commin'. Ok, maybe I
got a little carried away there... ;-).

> However, if there's enough demand, maybe we could add a
> "-slowerBiggerPrettier" compiler flag :-) I'm kidding, of course.

Actually, I think there would be value is a -nonoptimized mode that
would retain compatibility. It's not the typical use case, but
interoperability with the rest of the web echo system is paramount to
some and this is a great tool that could be adopted by those who are
driven by that kind of requirement. In building reusable components,
this would probably be a big win. A given widget could be reused more
effectively by more traditional web shops too.

Josson Smith

unread,
Oct 3, 2006, 3:41:30 PM10/3/06
to Google-We...@googlegroups.com
br...@google.com wrote:
> I can tell you the motivation behind GWT's code generation: to be as
> small and as efficient as possible :-)
>
> A few interesting specifics...
>
> - We do explicitly remove polymorphism as much as possible. Calls that
> are polymorphic at runtime take longer to dispatch and require extra
> code to set up. So, we do whole program analysis to turn polymorphic
> calls into static ones wherever possible.
>
> - Static calls can often be inlined, which can be a big win for simple
> methods.
>
> - Even if we don't inline, knowing exactly which method is being called
> statically allows the compiler to discard more code. For example, what
> if a superclass method is always overidden, so that the superclass
> method could never be called? The compiler can identify this and
> completely remove the method in the superclass. That alone saves code,
> and even better, may cause several other classes not to be instantiated
> (e.g. locals in the superclass method), which increases the odds that
> an entire class may be able to be discarded. And so on, recursively...
>
>

"To be as small and as efficient as possible"! I admire GWT team for
their excellent 100k ~ 200k final *.js files with very good performance.

Java2Script (http://j2s.sourceforge.net/), as mentioned, is a similar
project for Java to JavaScript code generation. But the motivation in
Java2Script is something different: "To provide same familiar Java APIs
in JavaScript".

I am just a lazy developer, lazy to learn new APIs for some same
functions. For example, Swing and SWT are similar GUI toolkit. And using
SWT can do all the things that Swing can do and vice versa. I would be
lazy to learn one of them only and not to learn the other. And I prefer
to SWT. And as now I am familiar with SWT, and if all things done by
using GWT can be done by using SWT, I would be lazy not to learn the new
GWT APIs but use my familiar SWT. So this lazy programmer will use
Java2Script and its Java2Script SWT library.

In order to provide the same familiar Java APIs in JavaScript,
Java2Script has to keep all fields, all methods, all inheritances and
all polymorphic information of a class in the JavaScript codes so
developer will always be happy and feel comfortable with those familiar
APIs. Java2Script is actually providing compiler that compiles Java
sources into static JavaScript libraries.

And following, I will just try to figure out my understanding of GWT's
Java to JavaScript compiling procedure. If I am wrong, please be kind to
correct me.

GWT's compiling procedure is somewhat similar to the procedure of
compiling C sources into an executable file. In C compiling, C source is
first compiled into an *.obj. And then comes a linker, which will link
*.obj with other *.lib files into an *.exe. In the linking procedure,
not all method calls in those *.lib are linked into *.exe file. Only
those which are used in the *.obj will be kept. Others may be discarded
so the final *.exe is small and efficient. In order to find out which
methods must be kept in linking, some recursive searching algorithm may
be required.

In GWT compiling, there are no middle *.obj actually. GWT compiler
tracks down those method calls which are related to the application. And
if the other methods have no relationship with the application, they
will be discarded even they are marked "public". So the final *.js is
very small and efficient. Those class meta information discarded may
include class inheritances, overriding, polymorphisms and other OO
information. So after compiling, there are actually not OO JavaScript.
So OO concepts like "this" keyword or reflection calls can not be used.
In the whole compiling, the key technology of GWT may be the algorithm
to flat those super calls and polymorphic method calls into static calls
correctly.

And I admire GWT team for their excellent 100k ~ 200k final *.js files
with very good performance.

Even basing on the same JDT toolkit, compilers with different
motivations result in different JavaScripts. In a comparison,
Java2Script generates 500k+ *.js files, and has its bottleneck on long
waiting on loading those bundles of huge *.js files and poor performance
on spending most of its CPU time in searching for polymorphic method
calls. In fact, Java2Script has many optimizations on reducing the
generated *.js file size and improving JavaScript performance, like
minimizing variable name identities, generating smart scripts to avoid
polymorphic method calls and others. But it seems that Java2Script is
still far behind GWT in file size and performance.

But GWT, as the above compiling process described, may have its
difficulties in supporting Java refection and dynamical class loading.
But Java2Script already has its ClassLoader and is loading classes
lazily. And it also has its early Java reflection implementation on
JUnit tests (Reusing JUnit tests directly). But the way, GWT APIs and
Java2Script SWT APIs is far different for comparison.

In some simple words, GWT compiler is an excellent Java to JavaScript
*runtime compiler*, while Java2Script is a Java to JavaScript *library
compiler*.

Maybe GWT would be kind to support Java reflection and dynamic class
loading, if more developers vote for such features.

Regards

br...@google.com

unread,
Oct 3, 2006, 5:47:39 PM10/3/06
to Google Web Toolkit
claude wrote:
> ... It's not the typical use case, but

> interoperability with the rest of the web echo system is paramount to
> some and this is a great tool that could be adopted by those who are
> driven by that kind of requirement.

I didn't mean to appear to be rejecting the idea of nice, simple JS
compatibility -- far from it. Automatically generating familiar
JS-compatible APIs is something we will be thinking about pretty soon.
There's no question that great JS API generation would be valuable for
interop, or simply as a way of publishing your widgets to users who
don't know/like Java or don't use GWT.

I guess the thing I really didn't make clear is that in my mind it's
two separate goals:
(1) Create highly optimized JS output
(2) Optionally, publish selected parts of your code with a
JS-compatible API

I don't want to sacrifice #1 to get #2, because I'm certain that with
the right design and thought (and hard work), we can have both at once.

-- Bruce

br...@google.com

unread,
Oct 3, 2006, 6:29:49 PM10/3/06
to Google Web Toolkit
Josson,

Dynamic class loading and reflection are cool features, no doubt, and I
think it's awesome that your compiler is able to cross-compile so many
of the existing Java idioms as-is.

I think several of us on the GWT team would have a hard time justifying
supporting those features in GWT for several big reasons:

1) They completely devastate the compiler's ability to optimize
aggressively. How can the compiler remove code when some subtle
reflection logic might actually need it at runtime? How can the
compiler fully understand the call graph?

2) Reflection and dynamic loading are affordable when running JITted
bytecode on 2GHz CPUs and when you can load new classes directly from
disk (or from a filesystem cache in RAM). However, it's a whole
different story when you consider paying those extra costs on top of an
already-interpreted scripting language.

3) Dynamic class loading and reflection both introduce the possibility
of new kinds of runtime errors. Things like "method not found" and
"class not found on server" seem like things you'd want to avoid, so to
me GWT's "limitation" is actually an aid to quality.

4) Loading code dynamically over HTTP has two big weirdnesses. First,
at what granularity do you load code dynamically? Per class? I guess
that's what the ClassLoader model would dictate. But if that's true,
then that is a *huge* number of HTTP round-trips...and a network hiccup
during any one of them would stall the entire application. Second,
more subtle, is that ClassLoader.loadClass() is synchronous. That
means, I guess, that to implement it you have to use XMLHttpRequest in
synchronous mode to fetch the JS of a class, but that causes terrible
browser behavior in that it locks up the chrome completely (and in FF
it actually pegs the CPU, too). [That's why GWT doesn't do blocking
RPC calls at all!]

In GWT, we do compile-time code generation instead of runtime
reflection. GWT code generators are free to use reflection to spit out
non-reflective translatable code. That way, you get the advantages of
reflection, but only at compile-time. The generated source can be
optimized just like handwritten code.

Those are just some thoughts while I'm killing time here in a hotel
room at JAOO. I'd like to hear your thoughts if you see things
differently or if you've solved the problem in some clever way we never
thought of.

-- Bruce

ash

unread,
Oct 3, 2006, 10:22:42 PM10/3/06
to Google Web Toolkit
first let me thank you both for participating in a thread that is close
to my heart. clearly both of you are the domain experts in these
respective technologies and i value these discussions.

in a different thread, i spoke about the gwt design principles. these
principles have always aligned well with me and my values since the
first day i discovered gwt, warts and all.

however, there is one principle or motivation that i value which
appears to be causing tension. we have all experienced conflicting or
competing principles, but it only becomes an issue when a principle is
so highly valued.

josson hinted at it when he said he was a lazy developer. but there is
more to it than that.

the reason why i have had the thoughts of quitting my day job and
joining either josson's or Arno Puder's (xml11 guy) crusade is because
they both are geared towards:
- minimise re-invention and leverage as much as you can

background
in my first large gwt application i found myself porting parts of
apache commons lang. i found myself being constrained by the emulation
JRE subsystem. at the time i had a deadline and i was so high on
smoking what the gwt team was shipping that it didnt really matter. but
after a while the two things that i disliked most about gwt (ie. 1.
limited JRE and 2. the ui widget library) started to take its toll.
even though i _love_ so much of gwt's concepts and architecture, i
found myself investigating other options. why? because:
* i dont want see all these core oss java projects being duplicated and
ported to gwt (like i found myself doing)
* clearly there is more to an oss project than the codebase, there is
the thinking, the community, the test-suite. many social things do not
make the port
* there are standard and/or defacto standard projects that large
organisations have approved for consumption as part of their software
governance. gwt ports of these projects would not stand a chance.
* the ui widgets and their layout consistency lacks the crispness of
alternatives without significant domain knowledge in css and some
graphics skills
* up until recently when konstantin shipped his gwt designer, i needed
introspection and reflection and i knew late binding wouldnt cut it. i
also started to feel the need for dynamically linked modules.


i dont expect gwt to solve world hunger, but i could see how the
tension points identified above could possibly be addressed with either
j2s or xml11.

perhaps the fact that these other oss projects are so under resourced
is a good thing because they are forced to leverage well known
libraries, idioms, and standards and honour the reuse/release
equivalence principle for common oss java assets.

---

bruce, what does a healthy gwt community look like?
to me based on our current trajectory:
* there a lot of small, fragmented and duplicated widget offerings that
attempt to simulate the standard desktop widget set available in
swing/swt/winforms.
* there is a jaxen port and probably more other ports out there. (it is
creditable that this has been done, but should it have been done?)

at the moment, having a large organisation depend on any of these oss
offerings is currently considered a risk which prohibits enterprise
adoption. which brings me to "are we on the right trajectory?"
please dont get me wrong, i want gwt to be the killer development
platform, but i feel that many of our current community outcomes are a
direct result of that one neglected principle.


best wishes
ash
http://gworks.com.au

georgeuoa

unread,
Oct 4, 2006, 12:56:32 AM10/4/06
to Google Web Toolkit
I believe reflection will be easy to add from a developer's point of
view to GWT once browsers are equipped with better javascript
engines... and projects like j2js will benefit far more from them than
gwt will. So far I'm happy about the really small code GWT produces
since I live & work in a region where a fast internet connection still
is a previlege.

There are actually good reasons justifying dynamic code loading. One
application I wrote rendered XML into widgets, which caused the browser
to download a huge arsenal of widgets when the forms displayed actually
involved merely a small subset of them. I propose that code loading
occurs on a per 'jar' basis, loading a set of classes at once, grouped
manually together by the programmer. In respect to the need for
asynchronous loading, I'd be comfortable with observing the load
operation like:

GWT.create(SomeClassName, new AsyncCallback(){
void onSuccess(Class c){

}
...
}
);

... or whatever in this direction is that you feel appropriate provided
that once onSuccess is called, code in the main application that
explicitly refers to the class like:

SomeClass obj = new SomeClass();

will execute fine and not throw a ClassNotFoundException.

Bruce Johnson

unread,
Oct 4, 2006, 2:40:51 AM10/4/06
to Google-We...@googlegroups.com
On 10/4/06, georgeuoa <g.georgo...@gmail.com> wrote:

I believe reflection will be easy to add from a developer's point of
view to GWT once browsers are equipped with better javascript
engines... and projects like j2js will benefit far more from them than
gwt will.

I didn't mean to imply that some form of reflection would be *difficult* to support in GWT, just that it doesn't seem affordable at present.  If it ever becomes affordable (don't hold your breath :-) and people want it, then I could see it happening in GWT.

So far I'm happy about the really small code GWT produces
since I live & work in a region where a fast internet connection still
is a previlege.

Great!  We still want to make the code smaller and faster.

There are actually good reasons justifying dynamic code loading [...] I propose that code loading
occurs on a per 'jar' basis, loading a set of classes at once, grouped
manually together by the programmer.

Something like jar-at-a-time makes sense to me, too.  I think what you're describing matches up with what we all discussed on the big thread talking about dynamic loading: <http://groups.google.com/group/Google-Web-Toolkit/browse_frm/thread/ab7644cd8c0de7f8>.

I completely understand the need for dynamic loading -- in fact, that's going to be in the works after 1.2.  I just meant that the ClassLoader technique  (i.e. loading one class at a time) specifically isn't a good match for the realities of the browser and HTTP. 

In respect to the need for
asynchronous loading, I'd be comfortable with observing the load
operation like: [...]

That seems to have the right kind of feel: it doesn't pretend to be Class.forName(), but it's still relatively simple.

-- Bruce

Josson Smith

unread,
Oct 4, 2006, 4:48:12 AM10/4/06
to Google-We...@googlegroups.com
Hi Bruce,

First, there are no clever ways for ClassLoader.
Second, in my conception, there are another term "asynchronous
programming" besides "synchronous programming".
Third, Java2Script compiler does perform very poorly at loading huge
arsenal of SWT classes.

In the implementation of Java2Script ClassLoader (not full APIs
implemented), it mainly supports three modes:
1. Asynchronous over SCRIPT tags (mainly in used)
2. Asynchronous over XMLHttpRequest (not used a lot)
3. Synchronous over XMLHttpRequest (seldom used),

Up until now, I seldom use ClassLoader.loadClass in synchronous XHR
mode, as the browser may be locked. Instead, an asynchronous ClassLoader
wrapper is introduced:

public class AClass {
// Java2Script compiler will generate different scripts without
Thread for this method body
public static void load(final String clazzName, final Runnable
afterLoaded) {
new Thread(new Runnable() {
public void run() {
try {
Class clz = Class.forName(clazzName);
if (afterLoaded instanceof ARunnable) {
ARunnable runnable = (ARunnable) afterLoaded;
runnable.setClazz(clz);
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
return ;
}
afterLoaded.run();
}
}).start();
}
}

Java2Script recommends using this kind of asynchronous ClassLoader, in
which the compiler will modify AClass.load with JavaScript codes without
java.lang.Thread but with asynchronous XMLHttpRequest or SCRIPT-tag
class loading codes.

And now it comes to something about "Asynchronous Programming" v.s.
"Synchronous Programming", if we use asynchronous class loading.

We know that JavaScript does not support Thread like Java. But when you
use Java, lots of Thread things will be introduced. For example, when
you use GUI toolkit to open a dialog, there are threads running
already. But when we introduce UI widgets in JavaScript, we have no
Threads. What we can use are asynchronous callbacks. And we do use use
asynchronous callbacks a lot in XMLHttpRequest. So if we take
asynchronous callbacks for granted, we should always considering
"Asynchronous Programming" pattern. That is to say, when we know some
calls are *time-consuming*, we should put following codes into a
callback and let that method call to call back later. So RPC and
Class.forName call should be wrapped into a callback by developer
intentionally.

Here is an example for scenario of using asynchronous class loader.
There is a page, with many tabs. And each tab will present a different
thing (a different class). We need not to load all those tab classes in
starting up. We just need to load that tab class only when user switches
to that tab. When user switches, here asynchronous class loader should
be used to load the tab page class:

tabFolder.addSelectionListener(new SelectionAdapter() {
public void widgetSelected(SelectionEvent e) {
//...
Object data = item.getData(); // class name
actually
if (data != null) {
// ASWTClass#shellLoad is actually
similar to AClass#load

ASWTClass.shellLoad(tabFolder.getShell(), (String) data, new ARunnable() {
public void run() {
try {
Constructor constructor =
getClazz().getConstructor(new Class[] {ControlExample.class});
Object inst =
constructor.newInstance(new Object[] {ControlExample.this});
Tab tab = (Tab) inst;
// ... do the following
layout job
} catch (Throwable e) {
e.printStackTrace();
throw (Error) e;
}
}
});
}
}
});

Here when asynchronous class loader is loading classes, show some texts
saying "fetching data ..." should be fine.

The problem of *huge* number of HTTP round-trips is a *huge* problem of
Java2Script compiler. So packed *.z.js, which is similar to *.jar, is
introduced. First ClassLoader is designed to load class in per class
mode but is also designed to load all related classes when one class is
required. For example, when instantiating class A must require
instantiating class B, then ClassLoader will try to load class B when
class A is required, and only marks class A as loaded after class B or
other classes are loaded. This may require algorithm to calculate class
dependencies, which may be similar to GWT's call graph. So if class A
and class B have their relationship, we can pack A.js and B.js together
to reduce the number of HTTP round-trips. In practical implementation of
J2S' SWT, ToolBar and ToolItem are packed as ToolBar.z.js, Shell.js,
Decorations.js and Display.js are packed as Shell.z.js. This is a way
Java2Script compiler trying to reduce *huge* number of HTTP round-trips.
But as mentioned, the loading performance is not good enough. And the
packing algorithm may require professional design besides compiler's
capabilities.

Actually, the original design was to pack most of library *.js into
some (less than 15 or 20) *.z.js files. And those *.z.js are static with
different release versions. Other pages (or other websites' pages) may
load these static libraries when necessary. As different pages have
common *.z.js URLs. There are no needs to download them again once they
are already downloaded by other visited pages (Just like Flash is
required to install once). And if the *.js is distributed on a fast
network (like Google network or other distributed publishing network).
In fact, maybe these library *.z.js are not too huge for such publishing
and not small enough to be efficient libraries, as this design is not
yet proved.

GWT's *.js seems to be project-dependent. And different projects only
share a bootstrap library and not share some big *.js libraries (But do
share in Java source level). Am I right?

Currently Java2Script's ClassLoader just ignore "Class not found"
silently when SCRIPT-tag gets nothing. And this should be fixed. "Method
not found" exceptions existed already before Java reflection was
implemented.

As mentioned in my last post, I admired GWT team for the motivation of
"to be as small and as efficient as possible" and "excellent 100k ~ 200k
final *.js files with very good performance". And I learned that two

separate goals:
(1) Create highly optimized JS output
(2) Optionally, publish selected parts of your code with a JS-compatible API

For such design, without ClassLoader and Java reflection should be OK
for me. But I am still wondering whether it's a must feature or not for
enterprise edition of GWT projects. OK, I am just wondering from my lazy
perspective.

Maybe I should learn something from GWT's motivation and goals. Maybe
it's direction for JavaScript, also for Java2Script. And may be it's
not. No matter what, I learned that my early (in May) understanding of
GWT compiler was totally wrong. And thanks for Bruce, and thanks for
this thread and all participators, I have a better understanding of GWT
compiler now.

By the way, about "Asynchronous Programming" v.s. "Synchronous
Programming", I think there are should be something inside. And I are
wondering Java to JavaScript compiler should consider this seriously or not.

Regards

Josson Smith

unread,
Oct 4, 2006, 5:19:57 AM10/4/06
to Google-We...@googlegroups.com
Hi ash,

ash wrote:
> first let me thank you both for participating in a thread that is close
> to my heart. clearly both of you are the domain experts in these
> respective technologies and i value these discussions.
>
> in a different thread, i spoke about the gwt design principles. these
> principles have always aligned well with me and my values since the
> first day i discovered gwt, warts and all.
>
> however, there is one principle or motivation that i value which
> appears to be causing tension. we have all experienced conflicting or
> competing principles, but it only becomes an issue when a principle is
> so highly valued.
>
> josson hinted at it when he said he was a lazy developer. but there is
> more to it than that.
>
> the reason why i have had the thoughts of quitting my day job and
> joining either josson's or Arno Puder's (xml11 guy) crusade is because
> they both are geared towards:
> - minimise re-invention and leverage as much as you can
>

Yes, "minimise re-invention" was another motivation of Java2Script. Once
I had to design some wrappers to wrap Swing dialogs into SWT/JFace's
wizard-style dialogs, I got lots of pains. And when Java2Script ideas
came up, I did not think I could design a better UI framework than
JFace, so I chose to implement a JavaScript version of SWT library. By
such library, lots of GUI builders, and lots of other tools can be reused.

By the way, if you have any ideas or thoughts about Java2Script,
Java2Script team will appreciate for your discussion on its development
mail-list.


> background
> in my first large gwt application i found myself porting parts of
> apache commons lang. i found myself being constrained by the emulation
> JRE subsystem. at the time i had a deadline and i was so high on
> smoking what the gwt team was shipping that it didnt really matter. but
> after a while the two things that i disliked most about gwt (ie. 1.
> limited JRE and 2. the ui widget library) started to take its toll.
> even though i _love_ so much of gwt's concepts and architecture, i
> found myself investigating other options. why? because:
> * i dont want see all these core oss java projects being duplicated and
> ported to gwt (like i found myself doing)
>

Reusing existed OSS Java projects is challenging. An easy way to reuse
or port those projects should be developed.

Simulating desktop widgets is a unavoidable way to expand GWT. But what
about a stable API? Can GWT's API be stable sooner? Swing and SWT took
years to become stable. So it seems that a little longer waiting should
be required for stable GWT APIs.


> * there is a jaxen port and probably more other ports out there. (it is
> creditable that this has been done, but should it have been done?)
>
> at the moment, having a large organisation depend on any of these oss
> offerings is currently considered a risk which prohibits enterprise
> adoption. which brings me to "are we on the right trajectory?"
> please dont get me wrong, i want gwt to be the killer development
> platform, but i feel that many of our current community outcomes are a
> direct result of that one neglected principle.
>
>
> best wishes
> ash
> http://gworks.com.au
>
>
>

Regards

ash

unread,
Oct 6, 2006, 3:58:22 AM10/6/06
to Google Web Toolkit
Josson Smith wrote:
> By the way, if you have any ideas or thoughts about Java2Script,
> Java2Script team will appreciate for your discussion on its development
> mail-list.
thx for the invitation. ill cross post so both lists can take their dig
at me <g>. the purpose of this post is to present some random thoughts
that i have had.

josson,

thanks again for your contribution to the thread. i appreciate your
openness about the j2s classloader issues & ideas, and also your
interest in understanding the motivations of the gwt compiler.

i find myself routinely getting svn updates of your commits and
monitoring your progress. there is something that is very right about
your approach, that for me keeps gwt in check.

first, let me state where i think your project is positioned (pls
correct me where im wrong). i believe j2s is positioned b/n xml11 and
gwt. my rationale is:
* xml11 is server heavy and renders any awt based application to a
browser by sending delta DOM changes over the wire in a similar fashion
to ZK as one of its two approaches. there is work in progress to
support both swing and swt. the point being is that if you had existing
desktop java software that needed to be accessible via a browser, then
this may well become the most effective solution when xml11 maturity
improves.
* gwt is almost completely client based, has created a new ui widget
API that is coupled to the DOM, and does not attempt to leverage
existing java gui APIs


now lets discuss ui. note, whilst im not a huge fan of the gwt widget
API, there are the following things that i do like:
* it is very light weight
* it uses the clever gwt browser module strategy approach for
addressing browser independence
* it aims to be simple

to be honest, im not a big fan of swing or swt either. however, having
said that, what i do like about j2s is that:
1. java developers can leverage a matured, well understood, and
documented gui api
2. all widgets work out of the box (ie. no css files to hack)
3. it leverages an existing tools market built around swt

however, let us consider how important these points are to a community
like gwt. im sure the community will correct me where i am wrong.

> 1. java developers can leverage a well understood and documented gui api
sure there are many old swing/swt hacks that are in this community, but
to my surprise there are many non java folks. most of these guys would
probably look at swing/swt code and proclaim: "what the ...".
furthermore, there is a large advocacy for a middle ground between
social based web apps and traditional desktop style application in a
browser. perhaps this is where the openlazlo folks are headed. claude
has spoken at lengths on this subject (consider searching his posts) on
this group. therefore, should this motivation have a high priority as
we both originally anticipated?


> 2. all widgets work out of the box (ie. no css files to hack)
imho this is one of the most undervalued benefits of j2s. ive also
experienced this with zk and openlazlo - things just work without
configuration or deep knowledge. not only do u provide a near complete
swt widget impl., but it actually renders as expected. being part of
the client/server generation and developing apps in win3.1, win95, etc.
it became evident what tooling was required to attract the masses. i
think gwt (or gwt tool community) has a long road ahead and relies too
heavily on css/graphic expertise for the masses to arrive any time
soon.


> 3. it leverages an existing tools market built around swt
here again is another instance of the "minimise duplication, maximise
leverage" prinicple. however, having enough weight behind gwt, there
are 2 tools at present to support gui building for gwt. i use
instantiations' windowsbuilder pro::gwt-designer edition which is
slowly doing to gwt, what it did for swing/swt. therefore again, should
is this motivation have a high priority as we both originally
antipicated.


finally, lets discuss some of the pain points experienced by some
members of the gwt community.
1. developing applications with modules that can be dynamically linked
and shared accross multiple modules/projects
2. the limited jre causes engineers to duplicate code from existing oss
java projects when required
3. there is no support for reflection. gwt does support a powerful
compile-time concept called defered binding. admittedly, most things
can be pushed to either defered binding or the server side, but very
occasionally you do discover the need for reflection

---

i have never looked at j2s and gwt as competitors, rather ive always
looked to complement gwt with j2s and attempt to address some the paint
points above. i have often thought wouldn't it be cool if:
* j2s could achieve a static (way ahead of time) compile like gcj and
render an entire appl as a single html/js like gwt, and/or offer a
partitioned html/js with shared objects (designers can choose with
compiler switches)
* j2s could let me statically link my library with apache commons lang
(etc.) and render a js that i could call from gwt. hence, whenever gwt
could not do the heavy lifting, i could turn to j2s.
* all of j2s's swt widgets could be synthesized into gwt, but leverage
the low level DOM and Event abstractions rather than gwt ui widget api.
this time focus on a more common listener interface, build drag'n'drop
into the base and also consider component serialization and convenient
component to component assignment

---

in your blog u felt that this thread became x v's y. im sorry u felt
like that. as indicated above, i and im sure many others here are
uninterested in competition, but better solution.

im convinced that there is a market for your work. what and how this
community can leverage it within the context of gwt depends on the
roadmap of gwt.

best wishes
ash
http://www.gworks.com.au

Josson Smith

unread,
Oct 7, 2006, 1:42:33 PM10/7/06
to Google-We...@googlegroups.com
ash wrote:
> Josson Smith wrote:
>
>> By the way, if you have any ideas or thoughts about Java2Script,
>> Java2Script team will appreciate for your discussion on its development
>> mail-list.
>>
> thx for the invitation. ill cross post so both lists can take their dig
> at me <g>. the purpose of this post is to present some random thoughts
> that i have had.
>
>

Thanks for your thoughts!

> josson,
>
> thanks again for your contribution to the thread. i appreciate your
> openness about the j2s classloader issues & ideas, and also your
> interest in understanding the motivations of the gwt compiler.
>
> i find myself routinely getting svn updates of your commits and
> monitoring your progress. there is something that is very right about
> your approach, that for me keeps gwt in check.
>
> first, let me state where i think your project is positioned (pls
> correct me where im wrong). i believe j2s is positioned b/n xml11 and
> gwt. my rationale is:
> * xml11 is server heavy and renders any awt based application to a
> browser by sending delta DOM changes over the wire in a similar fashion
> to ZK as one of its two approaches. there is work in progress to
> support both swing and swt. the point being is that if you had existing
> desktop java software that needed to be accessible via a browser, then
> this may well become the most effective solution when xml11 maturity
> improves.
> * gwt is almost completely client based, has created a new ui widget
> API that is coupled to the DOM, and does not attempt to leverage
> existing java gui APIs
>
>

Some of my earlier thoughts: As both client(browser) and server are implemented in Java, developers can add annotations (or javaDoc tag) to leverage whether a *static* method is executed on client side or on server side. For example, there is a task to compare two files. If such a task is executed on browser side, browser will read (HTTP GET) two files, and make the comparison and show differences. If such a task is executed on server side, the server reads two files and make the comparison and return differences to browser and the browser display them.

If most of the methods are marked as being executed on server side(in most cases, one of two methods would be marked so), it would be just the same as ZK or XML11.

Currently, J2S has not yet implemented the above javaDoc annotations. So, IMO, it is much more similar to GWT than to XML11 currently. That is to say, it's client based, with SWT APIs supported.


> now lets discuss ui. note, whilst im not a huge fan of the gwt widget
> API, there are the following things that i do like:
> * it is very light weight
> * it uses the clever gwt browser module strategy approach for
> addressing browser independence
> * it aims to be simple
>

One or two months ago, I realized that SWT is somewhat heavy for most RIAs' requirement.


> to be honest, im not a big fan of swing or swt either. however, having
> said that, what i do like about j2s is that:
> 1. java developers can leverage a matured, well understood, and
> documented gui api
> 2. all widgets work out of the box (ie. no css files to hack)
> 3. it leverages an existing tools market built around swt
>
> however, let us consider how important these points are to a community
> like gwt. im sure the community will correct me where i am wrong.
>
>
>> 1. java developers can leverage a well understood and documented gui api
>>
> sure there are many old swing/swt hacks that are in this community, but
> to my surprise there are many non java folks. most of these guys would
> probably look at swing/swt code and proclaim: "what the ...".
> furthermore, there is a large advocacy for a middle ground between
> social based web apps and traditional desktop style application in a
> browser. perhaps this is where the openlazlo folks are headed. claude
> has spoken at lengths on this subject (consider searching his posts) on
> this group. therefore, should this motivation have a high priority as
> we both originally anticipated?
>
>

Is GWT API on the way to be another similar Swing/SWT API? I wonder.

And when JavaScript SWT first demo came up, someone said, do we need
this complexity?.

>> 2. all widgets work out of the box (ie. no css files to hack)
>>
> imho this is one of the most undervalued benefits of j2s. ive also
> experienced this with zk and openlazlo - things just work without
> configuration or deep knowledge. not only do u provide a near complete
> swt widget impl., but it actually renders as expected. being part of
> the client/server generation and developing apps in win3.1, win95, etc.
> it became evident what tooling was required to attract the masses. i
> think gwt (or gwt tool community) has a long road ahead and relies too
> heavily on css/graphic expertise for the masses to arrive any time
> soon.
>
>

It seems that css/graphic experts would like to use CSS/HTML most.

Static compiler like gcj requires more hacks over Eclipse JDT. And it seems that GWT already implemented its static compiler. Maybe I may learn something more from GWT.


> * j2s could let me statically link my library with apache commons lang
> (etc.) and render a js that i could call from gwt. hence, whenever gwt
> could not do the heavy lifting, i could turn to j2s.
> * all of j2s's swt widgets could be synthesized into gwt, but leverage
> the low level DOM and Event abstractions rather than gwt ui widget api.
> this time focus on a more common listener interface, build drag'n'drop
> into the base and also consider component serialization and convenient
> component to component assignment
>
> ---
>
> in your blog u felt that this thread became x v's y. im sorry u felt
> like that. as indicated above, i and im sure many others here are
> uninterested in competition, but better solution.
>
>

I did not mean to be another "vs" thing. Yes, "better solution", the goal of open source software.


> im convinced that there is a market for your work. what and how this
> community can leverage it within the context of gwt depends on the
> roadmap of gwt.
>
> best wishes
> ash
> http://www.gworks.com.au
>
>

Regards

siarguk

unread,
Oct 10, 2006, 4:34:14 PM10/10/06
to Google Web Toolkit
Hi Bruce,

first of all you should know that we really value for what you did
guys. I have seen a lot of "pretty" and "full featured" solutions that
are dead now, because they didn't do what they were done for.

br...@google.com wrote:

> I'd like to hear your thoughts if you see things
> differently or if you've solved the problem in some clever way we never
> thought of.

You have already said "A" when you defined GWT Module-concept. You just
need to say "B" and ... define dependencies between the modules and put
them all together in one application. ;) IMHO it will be great
advantage to developers of big applications than.

1. Topology:
- application consists of modules
- module consists of classes
- application must have EntryPoint
- module can have EntryPoint

2. Compilation:
- the whole application with all its modules must be compiled at
once to keep all advantages of current design (optimized generated
javascript code and obfuscation)

3. Dynamic module loading:
- module is a minimal unit of loading
- loding of a new a module requires that all other modules it
depends on are loaded
- a module can use another module only if both modules were
compiled together

That's all. Using this concept I would design my application to have
for example
1) java.lang&util, GWT DOM&UI, my own widget's module (actually always
loaded)
2, 3, 4, 5, 6) different feature-grouped dynamically loaded modules of
my huge application (use module 1 and may also use each other)

What are your thoughts on this matter?

br
s.

Reply all
Reply to author
Forward
0 new messages