Re: Disabling the Sandbox
What is it, in this *trusted* applet, that requires trust?
Access to any part of the user's file system that the user wants us to
The user supplies the file name(s), by browsing or dragging and
onto the applet.
JWS. Drop the 'embedded in web page part' and this
is all doable in JWS.
For our purposes, if the user doesn't have control if their own
won't be using our app.
OK - that removes a lot of problems. Web start launch
can be made a lot smoother if the user can also be
expected to have JS enabled in their browser.
...If they don't have the right version, *it's up
plugin to be able to automatically update itself*. That's part of what
asking here. If the plugin cannot do that, I cannot use that plugin.
Java does auto-update, and for Win. user's it is relatively
transparent (as you describe below for Flash).
One of Java Web Start's main advantages beyond ensuring
the *application* is up to date, is to make sure the end-user
has the minimum required version of Java, to run it in the first
It is *our* responsibility as developers to go to our best effort to either
get the app. running, or to provide useful feedback to the user if that is
It is not my responsibility to ensure that Sun or Adobe has their act
I don't think you've put enough thought/research
yet into the 'other side' of doing things from the
internet. That is, the User Agent (read browser)
that is being asked to interact with either Flash,
or Java web start launched apps. (whether applet
This all comes to to the *serious* threat of getting
viruses or other malware off binaries from internet
sites. Sometimes a plug-in will attempt to do something
that is 'vetoed' by the browser (or the OS, or any
of a number of browser plug-ins (e.g. pop-up killers)
or anti-virus software).
The maker of the Plug-In only has so much control
over the decisions of the browser manufacturers
(and the rest of them) - most things are a matter of
negotiation, but Sun (no idea about the makers of
Flash) seems unwilling to take on browser manufacturers
for the sake of applets.
Look, the simplest option I can create for the *user* is to say "PC
here" and "Mac users click here", and let each download a platform
Is it? I have seen installers for Win. that curl up and
die with no clear error message.
But that is starting to sound like your app is not
'embedded' in a browser in any case.
..In that case, *I* can make sure that each binary works on
version of Windows or MacOS the user may have.
Can you make it work on that ol' 486 of mine?
I think it's running Win. 95. ;-)
From what I've seen of Flash, it seems to very keep itself udpated
transparently. If you don't have the required version, there's usually
here to get the latest version' button, maybe enough click to give the
appropriate permissions, and in minutes you're up to date. I don't
more than that without investigating further.
That level of user interaction is acceptable. What I *can't* have is
like "Sorry, you don't have the latest version of PLATFORM(tm), please
PLATFORM AUTHOR's website and download the latest version of the
RUNTIME(tm) and install it."
I think the current Java update situation is ..
- tranpsarent for Windows
- 'visit the site' for Mac.
...It pretty much needs to be a one-click
You're new to this whole 'trusted apps. embedded in a web page' type project,
I have no idea if this is new or old, I just have something I want to
do and am
trying to figure out what tool to do it with. I really don't care who
or what language it is. No technology religion here at all.
My point was not about competing tech., but having
(any) trusted app. within a browser window, or 'coming
at you' off the internet.
java.security.AccessControlException: access denied (java.io.FilePermission
'That will fail on a Mac.' You did say this was meant to run on Win & Mac.,
Why wouldn't it work?
Note the quotes, they indicated, ..
...That path is not hardcoded
..if you presume that path to be hard coded.
( I hoped that would become clear from my later
comments, but then I've hoped for a pony for a
long time, and (checks) ..no sign of that yet, either ;)
..(that's not even the
path, I edited the error message to make the path generic, rather than
reflecting my filesystem). That path comes from the user, via browsing
drag and drop.
I am relatively sure that D'n'D can be used in a
sandboxed JWS App., but have not checked it.
..I don't need to interact with the path contents at all,
than (in the case of Java) converting it to a String and showing it to
user, and passing it to a File object to access the file's contents.
The sandboxed JWS API does not allow you to get
access to a standard java.io.File object, instead you
work with a javax.jnlp.FileContents. It is similar, but
You mention JWS. Is that a one-click solution, or is the user going to
present with a "this application requires the latest version of the
Runtime(tm)" type of dialog?
If you app. requires Java 1.6, when the user has Java 1.4
(or 1.5, 1.3, 1.2 or 1.1) yes. If it is compatible with 1.4,
any user with 1.4, 1.5, 1.6.. can use it straight away.
Most of the file/access could be achieved in the JNLP
API that existed when it was first released (during Java
1.2), but for GUI elements, 1.4 was a significant
improvement. Java 1.5 added the ExtendedService to
the JNLP API that allows the user to avoid a file open
dialog when 'double click openning' a file with the app.
Java 1.2 has already been shelved (long ago) and
Java 1.4 should be going into EOL very soon.
Message posted via JavaKB.com