Deepak’s Blog

Wow.. been a while since my last update. I’ve been toiling away writing gobs of new code for the new NP plugin. With the initial framework now in place, I am finally seeing results.

Java can now set members on JavaScript side! It may sound like a simple thing, but there is a lot of work needed to make it happen. String exchanges, object creation via jni-like reference handles and reflection, multi-threaded  handling, etc. And that is also why I consider this an important milestone. A lot of the aforementioned items comprise the base framework. The fact that JS members can now be controlled, proves the stability of that framework.

I have uploaded a small clip here that shows this in action (this is applet used). When the mouse moves over the applet, a listener uses liveconnect to modify the value of the “Desired Altitude” element on the right. Similarly, moving the slider updates the “Maximum Cost” element.

Click here to see the clip

Updates to the field seem a tad slow in the clip, but that is just due to recording limitations. Updates are synchronous on the end machine. All of the code needed to do the above is now in the upstream mercurial repository.

Next on my list is to do something similar for JS->Java calls, implement a few basic functions and such.

Yes ladies and gentlemen, the future is here! (kinda… partly… well, okay just the beginning of it is here, but still!) IcedTeaNPPlugin is not the final name, but that it what I am calling it for the time being. As mentioned in my previous post, I’ve been working on a rewrite that uses NPRuntime. The new plugin is based on GCJWebPlugin. Only the side that talks to Mozilla is based on GCJ though. Since many strides were made on the Java side (NetX bridge, proxy support, cookie support, better tag parsing, etc.), I wanted to use the Java side from the new plugin. In order to do this, the C/C++ side had to be modified to send information like cookies, proxies, etc.  Furthermore, the new Java processing model is designed to handle multiple applets in a single VM. The C/C++ side therefore had to be adapted to be compatible with the new wire protocol.

I terms of testing, I tried out applets from the original GCJWebPlugin test list, and things seem to be fine.

I am now faced with decisions on how to implement the LiveConnect bridge. I have given this some thought, and I think the best approach is to rock the boat as little as possible.

OJI is a layer that talks to the LiveConnect code, which in turn “connects” JavaScript in Mozilla to Java. The LiveConnect/OJI code is pretty sound in terms of how it goes about doing this, and I think it is a good approach. Furthermore, the Java side is already tailored to work with this approach, and is stable. This is where the less boat rocking comes in. Since we have a chunk of C/C++ code that already talks to OJI, and Java code that can appropriately respond back, I think it makes a lot of sense to mimic OJI. This will allow a lot of code reuse, which is good from a time-line and bug perspective.

Of course, that does not mean it will be easy by any means. Gecko is removing LiveConnect/OJI for a reason — it is huge, and complicated to maintain given it’s sparse usage. Furthermore, that code talks to the JS engine, not to the NPRuntime api. This middle glue will all have to be rewritten.

And there you have it, my proposed solution to implementing LiveConnect in the new plugin. Over the coming few weeks, I am going to start with the small things like setting/getting variables, and move up to the more complex ones. As always, I will keep updating this blog with my progress!

The plugin is now upstream starting with this commit. For the time being, the plugin Java backend has been checked into a separate directory. While the C/C++ side is more or less compatible with the Java side, I had to still make minor changes on Java side. These changes (except 1 relating to FIFO pipe names) should work fine with the original IcedTeaPlugin, but I am uncomfortable changing things in a stable plugin during early development of another plugin. For now, I will do manual periodic synchs between the IcedTea Java backend and the new NP plugin Java backend. I believe it is easier than having to test every java side change against the current stable IcedTea plugin.

If you wish to give the new plugin a try, you can do so by building icedtea6 (bleeding edge version, configure it with –enable-npplugin) and linking to the $JAVA_HOME/jre/lib/<arch>/IcedTeaNPPlugin.so  from either ~/.mozilla/plugins or /usr/lib[,64]/mozilla/plugins/ . Be sure to check about:plugins to make sure only 1 Java plugin is seen, and that it is the IcedTeaNPPlugin.so one.

A few notes if you try it:

• The new plugin should be able to handle signed applets correctly, and is secure afaik. But if you try it, please do keep in mind that it is experimental.
• Currently, debug is “always on” (including the Java side debug server)
• Since LiveConnect is not yet supported, the plugin will freeze when trying to load applets that use it. This will be fixed in the next commit.

So after being poked and prodded by people (you know who you are.. you’re on my list now) to start a blog, here is my first post!

According to this post, it seems Gecko is going to definitely remove LiveConnect and OJI soon. I had heard whispers of this before, but people stopped talking when I got close. Probably because I stumble into discussions drunk and start rambling about how Picard was the best captain[1]… but we will never know. Anyway, now it is official.

This is a problem for the IcedTea plugin, which uses LiveConnect/OJI. Here is a brief history of things:

• Back in the day (before sliced bread and all) Mozilla plugins had an API called  NPAPI. This API was fine for most cases, but lacked scriptability (i.e. allowing  the page to interact with the plugin via Javascript in any significant manner, and vice-versa).

• To fulfill this need of scriptability for Java, a Javascript<->Java bridge called LiveConnect was developed. The older Sun Java plugin used this via an API called OJI.

• Around the end of 2004 (this date is from Wikipedia without citation, so it may not be accurate) browsers supporting NPAPI agreed on a new scriptable extension to NPAPI, known as NPRutime. Around 2007, Sun started working on a new plugin (libnpjp2.so) that uses NPRuntime. The new plugin is now the default.

With the Sun plugin having switched over to the new API, there are very few users of LiveConnect/OJI now and Gecko has decided to therefore remove it and reduce the maintenance burden.

As there is no date available for when the new Sun plugin will be released as Free Software[2], we’ve decided to start work on a new plugin that works via NPRuntime. The new plugin will be implemented in 2 phases:

1. Get normal Java applets working (including signed ones)
2. Get the Javascript<->Java bridge working

#1 is relatively easy, and will cover a large number of use cases. It is #2 that will be time consuming. Since NPRuntime is just an extension of NPAPI, that means that the older GCJ Web plugin (which uses NPAPI) can be used as a skeleton. That is the route I am currently taking. The idea is to modify GCJWebplugin so that it can use the new NetX-ified Java backend that IcedTea plugin uses, and consequently support signed applets, cookies, proxies, etc.

As stated in the message by Josh in the link above, Gecko will be making the change in 1.9.2 which will be the base for Firefox 3.6 due in Q2 2010. Bleeding edge distros like Fedora Rawhide will switch to Gecko 1.9.2 sooner than that of course, but it will still be a good few months before that. Hopefully it will be enough time for a rewrite! I am close to being done with the first phase. Next on my list is planning how we will be implementing the bridge, figuring out the necessary resource allocation, etc. I will keep updating this blog as things progress. Rest assured, we will try our best so that when OJI is removed there is a smooth transition to keep productivity at a minimum by allowing everyone to use Yahoo Games, Absolute Poker, etc.

1: Not that it needed saying, but still: I was kidding – I don’t stumble into discussions drunk and ramble about Star Trek. And as if Picard needs to be justified!

2: Edit: I should’ve reworded that. What I meant to say was that there is no confirmed release date. As per

http://openjdk.java.net/projects/jdk7/features/#f647

http://openjdk.java.net/projects/jdk7/milestones/

It is targetted for M4. However it cannot be confirmed and should that date be missed, it will be rather late to start a plugin rewrite and distros like Rawhide won’t have Java plugin support in that mean time. Hence the push for rewrite now…