This is a project that will require C++, Java, Qt, Boost, and other cross-platform Java/native skills.
As it's apparent now that the official Java Applet plugin will not evolve further and that the Java FX project focus on desktop rather than browser applets I think its time for a community effort.
In other news the lightspark project are working to create a free implementation of Adobe Flash. From my point of view they have the same problem that the Wine project have. They are trying to run application written for a badly documented proprietary product.
My plan are the following:
Create a plugin by forking icedtea web. This will reuse existing code while allowing us to change what we need to do different. First we will give our plugin a cool name that does not include Java or Applet (sorry but the FUD against Java needs to be avoided). Secondly we will not use the standard applet tag, because we will not be compatible. We will make sure that users can continue to run standard Java Applets with the existing plugins for their platform.
To make the platform secure and trustworthy we will stick to the original sandboxed applet model, we will not allow software to contain code that runs outside of the sandbox. With this we will avoid the main security problem with Java Applets.
As another security measure we will provide applets with a secure and reviewed API. We will not just allow them to access anything Oracle adds to the classpath, but each class and function will be reviewed from a security perspective. Many classpath classes could very well run inside the sandbox, and perhaps they will.
Accellerated 2D and 3D API: As we will not allow applets to ship with stuff like a signed OpenGL library but want to compete with flash we will have to ship our plugin with a class library gives applets access to 2D and 3D accelleration. The problem here are that direct access to API:s such as OpenGL are dangerous. For example OpenGL shaders can freeze the graphics pipeline (by not ending). Therefore I suggest scene graph library that by obvious reasons have to perform well while being secure. 2D could be implemented on top of a 3D API. However we have to make sure that we do not go down the Java 3D path which never made it to the classpath. Rather something lightweight and incomplete like WebGL, than something that we are unable to ship.
Last we need multimedia capacity which I suggest implementing by wrapping the Qt project. Qt have a lot of useful stuff that would be nice to wrap into our project. For example it have a media player API which Java lacks (JMF seam to be quite dead). By using Qt to play media our plugin can be used to for embeddable media players.
We will need both C++ developers that can work with the plugin and with native libraries like Qt and Boost. Ultimately we will have a modular design where a "QtPlugin" project makes it possible to write multi-browser plugins rather than just our plugin.
Hacking JNAerator to generate Java bindings our native code, or hacking our native code to play nice with JNAerator, will be other needes skills.
And of course making the actual classpath API:s that applets will be allowed to call will be a big part of our project. Without them there our plugin will be very uninteresting to users.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a project that will require C++, Java, Qt, Boost, and other cross-platform Java/native skills.
As it's apparent now that the official Java Applet plugin will not evolve further and that the Java FX project focus on desktop rather than browser applets I think its time for a community effort.
In other news the lightspark project are working to create a free implementation of Adobe Flash. From my point of view they have the same problem that the Wine project have. They are trying to run application written for a badly documented proprietary product.
My plan are the following:
Create a plugin by forking icedtea web. This will reuse existing code while allowing us to change what we need to do different. First we will give our plugin a cool name that does not include Java or Applet (sorry but the FUD against Java needs to be avoided). Secondly we will not use the standard applet tag, because we will not be compatible. We will make sure that users can continue to run standard Java Applets with the existing plugins for their platform.
To make the platform secure and trustworthy we will stick to the original sandboxed applet model, we will not allow software to contain code that runs outside of the sandbox. With this we will avoid the main security problem with Java Applets.
As another security measure we will provide applets with a secure and reviewed API. We will not just allow them to access anything Oracle adds to the classpath, but each class and function will be reviewed from a security perspective. Many classpath classes could very well run inside the sandbox, and perhaps they will.
Accellerated 2D and 3D API: As we will not allow applets to ship with stuff like a signed OpenGL library but want to compete with flash we will have to ship our plugin with a class library gives applets access to 2D and 3D accelleration. The problem here are that direct access to API:s such as OpenGL are dangerous. For example OpenGL shaders can freeze the graphics pipeline (by not ending). Therefore I suggest scene graph library that by obvious reasons have to perform well while being secure. 2D could be implemented on top of a 3D API. However we have to make sure that we do not go down the Java 3D path which never made it to the classpath. Rather something lightweight and incomplete like WebGL, than something that we are unable to ship.
Last we need multimedia capacity which I suggest implementing by wrapping the Qt project. Qt have a lot of useful stuff that would be nice to wrap into our project. For example it have a media player API which Java lacks (JMF seam to be quite dead). By using Qt to play media our plugin can be used to for embeddable media players.
We will need both C++ developers that can work with the plugin and with native libraries like Qt and Boost. Ultimately we will have a modular design where a "QtPlugin" project makes it possible to write multi-browser plugins rather than just our plugin.
Hacking JNAerator to generate Java bindings our native code, or hacking our native code to play nice with JNAerator, will be other needes skills.
And of course making the actual classpath API:s that applets will be allowed to call will be a big part of our project. Without them there our plugin will be very uninteresting to users.