Rescue DevMode via JavaFx and JavaPlugin?

201 views
Skip to first unread message

joerg.h...@googlemail.com

unread,
Jun 5, 2014, 8:07:44 AM6/5/14
to google-we...@googlegroups.com
Hi there,

just to bring in an idea that came to my mind:
JavaFx allows DOM integration and a bridge from Java to JavaScript in the Browser. The plugin is maintained by Oracle.
Would it be possible to tweak GWT such that a new DevMode could run as JavaFx app in the browser and a new CompilingClassLoader could redirect JSNI via JavaFx to the browser.
Does that make sense or do you think I am totally crazy or oversee a major problem...

p.s.: GWT is IMHO a major key to rescue Java and stop us from going to do JavaScript and Node.js on the server what means leaving the great eco-system we already have in Java and starting from scratch (I know we already have grunt and bower for maven or gradle, we have jslint for checkstyle, etc. but working without any abstraction directly against a database IMHO seems like ignoring all that we learned and archived in the past. We give up what we have with JDBC, JMS, JPA, CDI, etc.?). Maybe some more companies that rely on Java for their business should invest in GWT...

Regards
  Jörg

Thomas Broyer

unread,
Jun 5, 2014, 9:18:49 AM6/5/14
to google-we...@googlegroups.com


On Thursday, June 5, 2014 2:07:44 PM UTC+2, joerg.h...@googlemail.com wrote:
Hi there,

just to bring in an idea that came to my mind:
JavaFx allows DOM integration and a bridge from Java to JavaScript in the Browser. The plugin is maintained by Oracle.
Would it be possible to tweak GWT such that a new DevMode could run as JavaFx app in the browser and a new CompilingClassLoader could redirect JSNI via JavaFx to the browser.
Does that make sense or do you think I am totally crazy or oversee a major problem...

There 2 issues that affect the DevMode plugin, independently of the technology it's written in:

  1. calls from JS to Java and back have to be blocking. Chrome is removing the NPAPI, and the replacement PPAPI only supports non-blocking calls. One could build DevMode as a browser extension making use of the debugger APIs to set a breakpoint and manipulate variable values as a hack to pass values between the JS and Java world, but then there's the other issue:
  2. the plugin needs to be notified when a JS object is garbage-collected so it can tell the Java side of DevMode to free the memory for the corresponding Java object. If we don't have that, DevMode leaks memory like crazy. This is the kind of API that Mozilla removed in Firefox 27, and there's no existing alternative. I'm not sure Chrome's PPAPI would give us the information either.
So no, definitely, there's no way to "rescue" DevMode.

Ming-Yee Iu

unread,
May 30, 2015, 10:07:38 PM5/30/15
to google-we...@googlegroups.com
Actually, I've been curious about this for a long time too. I finally set aside some time to try it out, and it seems like it might be a viable approach (at least, I was able to get the Hello example running).

I was able to get a "gwt plugin" working in the JavaFx WebView with < 500 lines of code. A lot of the necessary code already exists as part of the GWT unit tests, so I was able to just take a peek at how things worked over there and do a similar thing with JavaFx. There's one thing that the GWT plugin seems to do that I don't think is possible with JavaFx, which is it allows JavaScript to treat Java objects like arrays. I'm not sure if that feature is actually used anywhere, so it might not be a problem. There's also a potential issue with the fact that the JavaFx WebView uses ancient LiveScript conventions from the Netscape days for interfacing Java with JavaScript. So it's not possible to differentiate between undefined values and the string "undefined," for example. Also, it looked like JavaFx might crash if a Java exception propagates through to the JavaScript side, but I didn't bother to really dig into that to see what was going on.

Doing a cursory search, I actually wasn't able to find anything in the plugin for letting the JavaScript engine send GC information back to the server. I think the GWT UI framework was designed so that there won't really be pointers from the JS side to the Java side, so the Java side can be in charge of all the memory management (in fact, the Java side does tell the JS side when to delete JS objects). I didn't dig too deeply though. I just implemented enough to get the Hello example working.

If you're interested, I can try cleaning up the code and checking it in somewhere.

-Ming

salk31

unread,
Jun 1, 2015, 9:31:33 AM6/1/15
to google-we...@googlegroups.com
Isn't one of the problems going to be things like JsInterop that require all the code to be JS?

Ming-Yee Iu

unread,
Jun 2, 2015, 12:11:48 AM6/2/15
to google-we...@googlegroups.com
I have no idea. I find the GWT roadmap to be a little opaque, and everything always arrives a couple of years after when it's promised to arrive, so I usually don't pay attention to what's in development until it actually gets released.

In any case, there's still a bunch of enterprise people doing GWT stuff. Even though Google has no interest in supporting legacy GWT stuff, I imagine there are firms that are willing to do support for those enterprise people, and I thought maybe they would be interested since it's not a lot of code.

I'm actually planning on going in a different direction (the plugin works differently than how I expected it to), so I have no use for a WebKit DevMode plugin that runs in Java, so I was just throwing it out there in case anyone was interested in dabbling in it further.
Reply all
Reply to author
Forward
0 new messages