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.
