Re: Disabling the Sandbox
Andrew Thompson wrote:
Roedy Green wrote:
I think someone said AppletViewer has no sandbox.
Correct. (AV is also used by JWS to launch applets,
and JWS imposes a sandbox, but that is not relevant
to the type of use of the AV to which you refer).
The appletviewer sandbox works for me.
Note, you can read (only) files from the path that the your classes are
loaded from. That is necessary to, for instance, load resources and the
class files themselves. Way back in 1.1, it classes on the classpath
were treated as privileged (there was not the distinction of system and
bot class loader back then). Applets often had a codebase of the current
working directory, which was also used by the default classpath. IIRC,
this meant they were loaded by the system class loader and given full
privileges. This is not a problem for Java 2 (first released 1998).
Applet support in the Java PlugIn and Java WebStart are extensions of
the appletviewer code. There are some technical differences. I think the
class loading is slightly different by default and PlugIn/WebStart, for
instance, allows printing to go ahead after a dialog without any
additional APIs. The source is of course available if you are interested.
You can make it a hybrid and run it as an application.
Yes. This can be good for simple applets, but might
require more work if the applet actively uses the
parameter map, or opens other URL's etc.
I think it well worth doing anyway.
Use an ANT script that does the signing. It takes only a second.
.the Ant solution for this day and age.
Or just a shell/batch file will do just as well.
My preferred solution is to run in the sandbox, with the extra
facilities Java WebStart gives you, or run as a normal application.
Don't sign anything unless you know what you are doing. I am not aware
of anyone who knows what they are doing.
Tom Hawtin