Posted by demonduck
on December 24, 2008 at 2:50 PM PST
Ok, a question:
deployJava.js works best with a dll called deploytk.dll. That dll "exposes" the functions/functionality
needed by deployJava.js. Correct?
DeployJava.js will work with any JRE but will be limited in function if that JRE didn't install
So I'm thinking, why not make a Java API (deploy.Deploy) that also can access the functionality of deploytk.dll
so that an applet can check at run time to see if the JRE that's running it is current. Then
the programmer can take necessary actions to encorage the user to install an updated
Let's say the applet is programmed to expect this new Deploy API to exist and the first
call it makes is a test call to a specific method in Deploy that either returns true or
throws a NoDeployToolkitException in a try/catch block and the catch block does the
right thing if the test in the try block throws an exception.
If the NoDeployToolkitException is caught, then the applet programmer will know that
a current JRE is not installed and then the programmer could then decide to prompt the
user to get the latest JRE or not whatever the programmer chooses to do.
If no exception is thrown, then a current JRE is installed and the applet programmer can
use the Deploy API to check the release level and suggest an updated JRE or not as
necessary to run the applet.
For example: let's say the applet is designed to use do 3D graphics with the latest
version of JOGL and the installed JRE -- while recent -- has an earlier version of JOGL
that lacks some specific capability that the applet programmer needs for his applet.
The applet programmer could either suggest a JRE upgrade or employ a builtin workaround.
So -- you ask -- what if there is no JRE installed? Well, then there would be a plugin missing
notice given to the user and if the user decided to install a JRE, he would get the latest
greatest JRE. This would be the fail safe fall back plan.
This would not replace deployJava.js but would get around the specific problem of
to use deployJava.js if one chooses to.
But I'm comfortable with Java and Java is a LOT easier to debug if you have a programming error.
And it avoids browser problems like needing FF3 rather than
FF2 to get the full functionality of deployJava.js.