Please provide Java bridge in Gears

[GoogleCodeExporter]

It would be great if Gears provided a "java" object in Javascript that
could be used to invoke Java methods directly from Javascript code, e.g.

if (java.available()) {
  var v = java.version();
  java.load("myProgram.jar");
  var result = java.MyClass.getMyStaticValue(jsParam);
  var javaObj = new java.MyClass(jsParam2);  // or use a factory method
  javaObj.modifyDom(jsParam3);
}

This basically provides a stop-gap for lack of Java scripting support
directly in the browser, e.g. onClick="java:MyClass.myStaticMethod();",
which is much more difficult to implement because if arbitrary Java syntax
were allowed, a Java compiler would also have to be integrated into the web
browser.

Ideally Java methods and objects would be accessible and manipulable from
Javascript, as well as vice versa, and the DOM should also be accessible
from Java (presumably through a synchronized interface to honor the
single-threadedness requirement).

Giving Java direct access to the DOM will allow for *amazing* new
possibilities for Web development, as well as providing a very interesting
new HTML/CSS UI layer for Java apps.  This will liberate Java from the
constraints of the embedded applet frame the way that the canvas element
liberates SVG to be a first-class citizen in the browser.  Additionally,
Java could be used to do the "heavy computational lifting" for web apps, as
Java code could easily be invoked as a Gears worker thread.  Debugging and
testing web apps would also be much easier using tools like Eclipse for
end-to-end client/server Java web app development.

From what I can tell, most of the hard work to implement this across all
major browsers and platforms has already been done in Gears.

Original issue reported on code.google.com by luke.hutch on 1 Feb 2008 at 3:55

[GoogleCodeExporter]

Indeed -- this echoes the "alternate language workers" idea that I've been 
excited
about for a while.  You could imagine an ability for workers to execute Java / 
Python
/ ECMAScript4.

However, that wouldn't allow for DOM access from these alternate languages.  
It's
more aimed at heavy computation, and easier migration of existing code to web 
apps.

What did you have in mind re: amazing new possibilities if DOM access were 
available?

Original comment by cpri...@google.com on 1 Feb 2008 at 6:30

• Changed state: Accepted
• Added labels: Version-later
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Yes, the natural extension of this is of course to support multiple languages, 
and
I'm certain the Python guys will want to be next. :)  I have been excited about 
this
idea since I was working at Google (and was going to add this to Gears as a 20%
project, but ran out of time)...

DOM access is definitely possible as long as calling JS functions from Java is
possible, because you can just write the DOM accessors in JS, and then wrap 
them in
function calls!  It would be faster to actually write a bridge that gives direct
access to the DOM, but I'm sure it would be more work.

The possibilities that are opened up with DOM access are on one level analogous 
to
some of the possibilities for SVG scripting and animation that native SVG 
support
adds to the browser, but for UIs rather than for vector graphics.  Java has been
"almost there" in the browser and on the desktop for a very long time, but 
sandboxing
your Java code to run in an applet window has never excited anyone, and the 
Swing
toolkit, though seemingly well-designed, is in practice painful to program for. 
 Once
taking up the full browser viewport for Java applets became possible, in the 
browser
realm at least Java wasn't confined to a sad rectangular subregion of the page, 
but
many of the same criticisms leveled at Flash still applied to Java: content was 
not
searchable or accessible, communication between the applet and the Javascript 
running
on the page was limited and clunky, etc.

The advantage to giving Java access to the DOM is simply that any web app that 
you
could write in JavaScript, you could now write directly in Java, and have 
HTML/CSS be
your UI toolkit, adding browser-native JS for extra scripting tasks with no 
extra effort.

Java is much more human-scalable for writing large libraries than Javascript, 
and
makes it easier to detect errors early due to static typing etc.  You also get
awesome refactoring tools in any modern IDE, Java is *much* easier to debug, a 
lot of
server-side code is written in Java so having the client code also totally in 
Java
makes a lot of sense both because you may not have to build and keep in sync two
business object representations, you can directly reuse code (libraries etc.) 
between
client and server, and there is an *enormous* amount of Java code out there 
that can
be leveraged to quickly put together much more complex applications than 
Javascript
currently allows (though JS libs are constantly getting better).  Java threading
support is also much more advanced than in JS, through the amazing
java.lang.concurrent package, which would be very useful for worker threads, 
etc. etc.

The other thing is that as you incrementally add first-class DOM-accessing 
citizens
to the browser, your cross-product of technology pairs grows quadratically -- 
e.g. in
this case, Java code will not only be able to access HTML nodes in the DOM, but 
also
SVG nodes, meaning that SVGs can be scripted with Java (and eventually movie 
elements
and other advanced HTML5 features, once those are available, e.g. the recent
WebKit/GStreamer integration work that Alp Toker blogged about).  This basically
makes a powerful web engine into much more of a Silverlight competitor than a 
plain
browser.

The main draw for me though is just having Java finally liberated from that 
pesky
gray applet box, and have it dwelling in the browser window as a first-class 
citizen...

I believe Gears probably has most of the code in place to do this already, 
because
the Gears team has already done the awesome heavy lifting of getting a bridge 
working
between JS and C/C++ on all the major platforms and browsers.  From there all 
that
needs to be written is some C/C++ stubs that call into Java (through the Sun
standardized interface), and the corresponding plumbing to be put in place in 
Gears
itself.  (Maybe I'm oversimplifying, but I'm pretty sure that though it may 
take some
work, it should be quite straightforward.)

Original comment by luke.hutch on 1 Feb 2008 at 10:43

[GoogleCodeExporter]

I should also mention the obvious point of speed -- Google knows better than 
anyone
how much JS execution speed matters once your web apps start getting really, 
really
big -- both app transfer time and execution time.

Also, the whole fact Google wrote a Java->JS translator so that you can code 
your web
apps in Java in the first place indicates there's a real programmer need and
justification for doing this: clearly if Java were available natively in the 
browser,
the more complex apps would just be written the way they are but run in the JVM
without the Java->JS translation step.

Original comment by luke.hutch on 1 Feb 2008 at 10:49

[GoogleCodeExporter]

FWIW, I am right there with you Luke. I've wanted this to exist for at least 
three years and it has always been a little bit too low priority. Java 
bindings to the DOM could be awesome in browsers, I think. Not just for workers.

Original comment by gears.te...@gmail.com on 1 Feb 2008 at 10:53

[GoogleCodeExporter]

Thanks for the show of support!  I think a lot of people would have liked this 
to
exist, but it really hasn't been possible until Gears, and isn't really doable 
in any
other practical way.  The alternative is having someone writing custom glue for 
the
cross-product of each platform,  each browser, and each new language.  Here once
basic support is in Gears, the glue only needs to be written for each new 
language.

PLUS I think the right timing for this is now -- I am very worried that if Java
doesn't get a head-start in the browser, then C# will nail it there too ;/
http://ejohn.org/blog/the-browser-scripting-revolution/  

Original comment by luke.hutch on 1 Feb 2008 at 11:02

[GoogleCodeExporter]

Speaking of C#, I totally wouldn't mind a C#/.NET bridge. That would be like 
stealing
candy from Silverlight.

Original comment by dimitri....@gmail.com on 1 Feb 2008 at 11:11

[GoogleCodeExporter]

One more motivating perspective on this issue, sorry to keep harping on :-)  The
Mozilla project spun off XULRunner at one point, hoping that they could 
leverage the
browser technology to create desktop applications while leveraging browser
technologies.  This has been slow to take off for numerous reasons, and instead
Ajax-style apps have taken off.  The Eclipse framework is another attempt at
producing a generic cross-platform framework for developing rich applications, 
but
has also generally been slow to take off, probably because of the overall 
complexity
of the platform.  Adding Java as a native browser language might just hit the 
sweet
spot between the two approaches, i.e. providing scalability reminiscent of the
Eclipse framework by allowing rapid development in Java, with the native fit to 
the
desktop, simplicity and advantages of modern web development:
-- most browsers now use native widgets
-- web standards provide simple and extensive control of element layout
-- browsers now support powerful built-in canvases

Original comment by luke.hutch on 16 Feb 2008 at 3:31

[GoogleCodeExporter]

What people really want is to leverage their java language knowledge to write 
web
apps. Making it a bridge to SUN's java is the last thing you must do. It is too 
heavy
a thing and that means relying on SUN jre being there in your device. Don't even
think about it. Those small devices cannot afford a foorprint of 60MB and a 
memory
footprint of kilobytes just for hello world! app. You must be thinking of iPone 
like
devices .And moreover , the standard java jar file is not a very efficient way 
of
packaging a binary and distributing.If at all there should be java support 
think of
something like the Dalvik VM (android). Keep the footprint extremely low. 

Original comment by noble.p...@gmail.com on 16 Apr 2008 at 3:20

[GoogleCodeExporter]

There is no reason why Android cannot take Java bytecode and translate it on 
the fly
into Dalvik bytecode, and then discard the jar source.  Currently all Java 
bytecode
to Dalvik bytecode translation is done on the desktop machine, and the resulting
.dex/.apk is installed on the handheld -- however, to support MIDP2 profiles and
eventually Java browser applets running natively on Dalvik, the compilation 
code will
no doubt get added to the Android stack itself.  There's just too much good 
Java code
out there for this not to happen, i.e. for Android to always rely on 
Java->Dalvik
compilation to happen on the desktop only.

Original comment by luke.hutch on 16 Apr 2008 at 3:33

[GoogleCodeExporter]

compilation is going to be an expensive operation for a device which is running 
on a
small cpu/battery. Think of the startup time too. 

Original comment by noble.p...@gmail.com on 17 Apr 2008 at 9:25

[GoogleCodeExporter]

Yes, but you have to amortize the cross-compile time across the runtime of the
application.  Dalvik was written specifically to be efficient on ARM-like CPUs, 
and
from what I know it achieves that quite well.  It is quite possible that the 
amount
of time and power spent running the Dalvik compiler just once on a .jar may 
save time
and power in the long run as the app runs for several minutes.  It also means 
you
don't need to install two VMs on your phone.  It's glorified JIT in a sense :-)

Original comment by luke.hutch on 17 Apr 2008 at 3:03

[GoogleCodeExporter]

Going forward the share of desktops will slide and smaller handheld devices will
increasingly become the mode of accessing web (iphone, symbian,android, windows
mobile etc). We can be reasonably sure that java * WILL NOT* be available with 
those
devices. So the question of 2 JVMs do not exist. Even desktops do not install 
Java
nowadays because none of the popular websites use java. 

Let us take a look at the requirements

# Users wish to leverage their java knowledge/libraries/tools .This can be 
currently
achieved using GWT but in a less desirable way
# The desire to have a language that is more scalable than JS(with static 
typing etc)
# Javascript is expensive to execute in terms of CPU/battery/time
# JS code is usually big . But jar file format also is too big

The solution is to have a totally different VM executing some form of byte 
code. The
bytecode must be optimized for size/execution and the VM should be optimized to 
have
minimal memory/storage footprint. This feature must not add not more than 1mb 
(or
slightly biggger) to the download size. JIT and other bells and whistles are 
just
"nice to have"

Original comment by noble.p...@gmail.com on 21 Jul 2008 at 5:36

[GoogleCodeExporter]

What does this achieve that the Java <applet> tag that most browsers already 
support
does not? Isn't exactly what you want already done about since about 10 years 
ago?

What am I missing, here?

Original comment by john.rip...@gmail.com on 21 Jul 2008 at 11:11

[GoogleCodeExporter]

<applet> sandboxes the Java VM and constrains it to a small child window 
embedded in
the webpage, making Java a second-class citizen in the browser.  First-class 
citizens
(currently just Javascript) are not constrained to run inside a small box 
embedded in
the page, they get full access to the DOM (or canvas, for more modern browsers) 
and
can be called directly in onClick events without writing some sort of bridge 
code. 
HTML was designed to allow other event-handling languages, hence the (proper)
prefixing of event handlers with "javascript:", but this functionality hasn't 
yet
been implemented by anyone.

IIRC, JS and Java/Flash originally didn't have a nice way of communicating with 
each
other, especially in a cross-browser way, but this was eventually remedied... 
however
you still have to write ugly glue logic to get Java and JS to talk to each 
other on
the same webpage.

Here's a more Gears-y / Googley application for using Java, which illustrates 
how the
suggestion in this application makes a lot of sense: if Java gets first-class 
browser
support, then Java threads can be used as Gears worker threads, and called
transparently from the main JS thread.  This would mean that browser-embedded 
data
visualization applications could do all sorts of cool CPU-intensive operations 
at
much faster speeds in the background (e.g. employing the numerous Java linear 
algebra
or matrix algebra libraries), and have the result of the computation updated by 
the
main JS thread.  There are plenty of other non-numerical applications I can 
think of
too, where you could move Java-powered work off the server to the client without
having to rewrite business logic code in JS: for example, you could wrap Java 
IMAP
and iCalendar code with some JS glue to produce a productivity application, 
without
trying to either re-write those protocol stacks in JS (probably almost 
impossible)
and without having to do all sorts of Ajaxy tricks to move as much computation 
as
possible to the server. 

Gears is already moving computation, storage and other capabilities into the 
browser,
enabling the building of web-native but "thicker" clients.  Having Java 
available
natively and as a first-class citizen in that world just makes a lot of sense.

Original comment by luke.hutch on 21 Jul 2008 at 2:51

[GoogleCodeExporter]

There is an existing solution called "LiveConnect" which allows Javascript and 
Java
to talk to each other. It's rather heavyweight, and there's a few links saying 
that
even Firefox is removing support in future.

The major reason why Java has had such a hard time gaining support in browsers 
is
because the standard libraries are ABSOLUTELY HUGE. There's nothing wrong with 
a Java
VM, and actually I confess that I think Java is a better language to use for 
complex
web apps, and bet produces smaller bytecode than the equivalent Javascript.

Still, 1MB is not a small binary increase, and I fear that the scope of this 
feature
is fairly large.

Does anyone have a figure for how big a .DLL (or equivalent) containing just a 
Java
VM is anyway?

Original comment by john.rip...@gmail.com on 21 Jul 2008 at 3:06

[GoogleCodeExporter]

There are some *very* small JVMs, especially on ARM devices where there is 
hardware
support (Jazelle) for bytecode execution.  Even a non-Jazelle JVM can be very 
small
(e.g. JamVM, 180k for Intel; kvm is even smaller and runs in environments with 
128kb
of RAM).

In reference to a previous comment, Java support on mobile devices has been 
held up,
in many cases, more by tricky porting issues with the VM and system libraries, 
and
less by the size of the standard libraries (citing the guy heading the effort 
to port
the JVM to Maemo, not my own opinion).  There are several small mobile device
profiles already available for Java, that get rid of the junk.  Also the size 
of the
standard libraries doesn't affect the memory footprint much, as classes are 
loaded on
demand.  Release 10 of JDK 1.6 dramatically improves startup time of applets and
reduces memory footprint even further.  

I don't think it's correct to say that Java will not be available with future
embedded devices, I think the opposite will be true, especially with Android 
catching on.

Original comment by luke.hutch on 21 Jul 2008 at 4:34

[GoogleCodeExporter]

PS see the Jalimo project for info on a coordinated F/OSS effort to bring 
several
alternative Java solutions to a range of embedded devices.
https://wiki.evolvis.org/jalimo/index.php/Main_Page

Original comment by luke.hutch on 21 Jul 2008 at 4:36