Friday, March 9th, 2007

JavaScript Native Interface (JSNI) in GWT

Category: Google, GWT, JavaScript, Library

<p>I have recently had quite a few people talking about how they like GWT but with they could get out of the Java box to delve into JavaScript for some low level work.

The assumption was that you cannot do this with GWT and that if you run against the abstraction barrier you are hosed.

There is actually a way to embed your own JavaScript directly.

JSNI has a similar name to JNI but isn’t as hairy, although it does have a creative hack.

To implement JSNI the GWT team overloaded the term native and used it for their own good:

  1. public static native void alert(String msg) /*-{
  2.   $wnd.alert(msg);
  3. }-*/;

Take a close look. Sneaky huh? The $wnd variable is your link to the window object, and if you need the DOM you simply use $doc.

The piece of JSNI that looks a little like JNI is how you access Java methods and fields directly from JavaScript.

Before you run off and start writing reams of JavaScript code, remember why you are using GWT in the first place, and use this as a last resort.

Related Content:

Posted by Dion Almaer at 10:01 am
11 Comments

+++--
3.7 rating from 44 votes

11 Comments »

Comments feed TrackBack URI

This is basically an admission that in the browser environment, JavaScript is king. If you ultimately need to fall back to JavaScript to fix your abstraction layer then your abstraction layer is leaking. JavaScript is king in the browser and GWT is for cowards.

Comment by Dean Edwards — March 9, 2007

Hold on Dean…I think calling GWT users cowards might be a little bit strong. There are alot of companies (mine included, Fortune 50…) that see the value of language homogeny. Rather than have the “web” team and the “Java” team, we can now have all developers work in a common syntax (Java) in a common IDE (Eclipse) using standard libraries and patterns – GWT for web, Eclipse RCP for fatter, internal clients, J2EE type of junk for middle tier type of stuff (I’m not a big server developer). I’ve spent years doing the XMLHTTP type of web clients, for internet use and intranet use. I can get more done quicker using GWT. From my bosses point of view, that makes my group not cowards, but just the opposite. At first it felt like we had to make some “concessions”…but ultimately, the way GWT handled it was well thought out and scales extremely well. Plus it’s immenently (sp?) debuggable and deployable…something that a lot of AJAXish types of projects have problems with….again, I’ve written a ton of them.

Comment by Mike Shaffer — March 9, 2007

We used the exact same hack back in the VisualAge for Java days. VAJ was written in VisualAge Smalltalk. Native methods in java were actually implemented in Smalltalk. I think we turned off the ability to do this for the production images; or just made it slightly hard to do.

Comment by Patrick Mueller — March 9, 2007

I agree with Dean. I haven’t been able to figure out why any capable browser script programmer would want to put a shaky abstraction layer on top of JavaScript for browser scripting. Browser scripting is a very difficult task and adding an inevitably restrictive and buggy layer between the developer and the action can only make the task more difficult. JavaScript is a high level language with many advantages of it’s own. It is not a language that needs to be replaced. Especially not with Java which has a very different set of features than JavaScript.

Comment by Peter Michaux — March 9, 2007

[from a recent post on the GWT forum when someone proposed adding Java threads to GWT]

In GWT, we try to be very aware of the reality of leaky abstractions.
When we consider new abstractions, especially very magic ones like
threads, they must fall into one of two categories:

1) If we *know* that an abstraction is going to leak, then we try to
make it obvious how the thing really works underneath, so that you can
view the abstraction more as a convenience than an attempt to actually
hide something. For example, we didn’t attempt to hide the continuum
between Widgets, Elements, and JSNI.

2) If we think we can create a genuinely reliable abstraction, then we
keep the surface area as small as possible to minimize the risk of
unexpected behaviors. For example, in RPC, the generated client-side
proxy code is really complex, but you never even realize it’s there.
We ensure at compile time that it won’t generate bad code if you
adhere to the RPC requirements, and RPC users can be blissfully
unaware of the underlying complexity. On the other hand, we truly
cannot provide *synchronous* RPC without the abstraction leaking
badly, so we don’t even try it — thus deferring to approach #1 on
that aspect of RPC.

Comment by Bruce Johnson — March 9, 2007

JSNI exists to allow you drop into javascript sure but why you would want to is another matter. Where it really shines is providing a mechanism to allow existing javascript libraries and components to slot into GWT applications. JSNI is the mechanism which facilitates communication both ways.

For example, there is already a GWT library which wraps the Google Maps api. I have used it and at no point did I have to drop out of the java code into javascript. It just worked. That my friends is JSNI’s killer feature, wrapping API’s. I have created wrappers myself which allow javascript components to mix with GWT widgets. Most of the effort was cranking out wrapper classes and hooking in event handlers to fire events both ways but at no time did I hit a point where I thought ‘this isn’t going to work’.

GWT is most definitely not a ‘shaky abstraction layer’ over javascript. Weirdly I think there is a certain amount of negativity towards it because it uses java and there are lots of ‘web developers’ who just don’t want to go near java. Dare I suggest that if you spent the last decade honing your knowledge of browser quirks and css that it might not feel more than a little threatening to find java programmers pushing into your ‘space’. I will use the tool that fits the job the best so from experience I can say that if you want to lay out an application using sound design principles then java will win hands down over javascript any day.

Scoff if you must but think about this: Flex, GWT and the many other frameworks mentioned on this site are already opening the door to the large traditional desktop ‘application’ community. When you can write an web app like you write a desktop app then there will be no need for ‘web designers’ anymore.

Comment by Alistair — March 9, 2007

Ok, so I’m a java guy and I don’t like it for similar reasons that Dean doesn’t. (obviously not exactly the same as I would then have to actually be Dean, which I’m not.. ;) )

You can say it’s because I have a personal investment in a “sort of” competing project but anyone that knows me knows I say what I feel is right “to a fault”…And I just don’t like this.

It’s not that I ~hate~ java – but I really enjoy the re-kindling of dynamic language dev that javascript and similar runtimes have to offer. I don’t really want or need anyone to keep me bottled up safely in the confines of java for the rest of my career – but thanks for offering.

Either way I can’t argue that the technology isn’t probably a good choice for some certain groups of development needs, be they big public websites or what I’m guessing is more normal – large corporate intranet / support / etc applications. This realm has never been anything I’ve really had an interest in so my opinions in that regard are probably suspect. ie I won’t bother ;)

Comment by Jesse Kuhnert — March 9, 2007

Alistair: I find your comments particularly confusing. While I may agree/think it’s actually cool to think of what is happening with JS3 and similar technologies – I fail to see how GWT has any relation to them at all…Some sort of web / desktop blend may happen, but it sure as shit isn’t going to be with java running on top of javascript.

That formula is backwards, I think you meant javascript on top of java. To be honest I don’t really know why google continues down this path when projects like Phobos / jMaki / flex / etc all are going a different direction. Maybe it’s just not liking to admit that they might have something wrong…Who knows ;)

You can line up 20 of the most powerful corporations and tell me all languages besides java are dead until you’re blue in the face but I’ll still look at you like you’ve lost your marbles…..

Comment by Jesse Kuhnert — March 9, 2007

God help me I don’t want to sound like a java zealout, far from it. I hate those guys as much as anyone else. My point(s) are

- JSNI is a seamless mechanism for connecting the java source through to any existing javascript components. There should be very little reason otherwise to do so. In my experience this is is what it is good at. It’s existence shouldn’t be mistaken as some sort of ‘cop out’ on the GWT designers part.

- IMHO the traditional ‘web designer’ community are entrenched in the idea of having to apply a spread of technologies to compose web sites. The idea of writing a webpage with only gives them the heebie jeebies as it renders all those special skills redundant in (more or less) one fell swoop.

Where does this leave existing javascript framework/libraries? I’m not sure. Something ‘like’ GWT shows there is another way. Google state on there blog that they chose java mostly because the available tools are so good. Where are the tools for javascript (and please don’t start comparing Firebug to something like Eclipse)?

Comment by Alistair — March 10, 2007

I think the GWT is great a project and I certainly understand why google’s heading in that direction. As far as “Google state on there blog that they chose java mostly because the available tools are so good.” I think they just choose java because that’s the #1 programming environmnent at google, so there’s corporate interest there and it would be naive not to consider it. Personally, I’d much rather see a powerful JS framework (like YUI or dojo) from google with the point being you shouldn’t need to learn java to build a web application. But it’s best to accept that there’s going to be convergeance both ways, microsoft’s already shown this with the WPF. I don’t use the GWT because you should be able to build a web app with HTML, CSS and JS. The java abstraction seems to me like a very useless step.

Comment by Jonathan — March 10, 2007

People here seem to just focus on the fact that GWT is an abstraction… it does promise a hell of a lot more for putting up with the spend:
*) internationalisation of content
*) debugging
*) the fact that you compile things means that all your object types are tested to a degree that you can never get with Javascript.
*) tight coupling to the server… within the same code see the boundary of client and server, and have GWT strongly form the service layer and still have your custom objects used on the server as in the client… awesome.
*) being able to cache the client code “until the sun explodes”

…I’m pretty sure there’s more, but these alone are very compelling. Now, I still don’t use GWT, but I’m very close to. Only reason I’m not is my familiarity with the browser environment… if you’re new to the browser, really, give GWT a think. It really does do a heck of a lot more than just abstract Javascript so you can write in Java.

Comment by Arron Bates — March 11, 2007

Leave a comment

You must be logged in to post a comment.