Hi, Nick. Thanks for your feedback. I'm glad to hear from someone who
has experience with App Store deployment.
On 9/6/13 2:17 PM, Nicholas Rahn wrote:
If you're saying that NSHomeDirectory is the correct behaviour for the Java
user.home property, then I have to disagree. On every other platform,
including non-sandboxed Mac, user.home is the actual user's home directory
(i.e. /home/<user> or /Users/<user> or C:\Users\<user>).
NSHomeDirectory still returns /Users/<user> on non-sandboxed Mac.
From my testing today, it seems the native Mac file dialog (which
underlies java.awt.FileDialog) does understand the "sandboxed"
NSHomeDirectory path. If you FileDialog.setDirectory() to it, the
dialog comes up showing /Users/<user>. This also works directories
contained in ~, such as ~/Documents.
(All this requires
com.apple.security.files.user-selected.[read-only|read-write], of course).
So that's a bit surprising, though it does mean that:
String userHomePath = System.getProperty("user.home");
myFileDialog.setDirectory(userHomePath + "/Documents");
will give you a FileDialog pointing to ~/Documents whether or not you're
running in the sandbox.
My understanding is that, when sandboxed, the *only* way to access files
within the User's "real" home directory is by selecting them in the
native file browser. And of course at that point, you can get the path
from the selected file.
The difference, then, is how user.home can be used outside the context
of a FileDialog. Currently, I think the answer when running in the
sandbox is "it can't" (unless there are other Entitlements that would
make the path to ~ accessible).
So the thinking here is that there is more value in having user.home
reflect an accessible location.
Setting user.home
to the *application's* home directory (which is what NSHomeDirectory
returns in a sandboxed environment) would seem to me to break the
definition of the user.home property.
>
On a mac, in a sandboxed and non-sandboxed environment, I would expect
user.home to be NSHomeDirectoryForUser.>
I can look into NSHomeDirectoryForUser. NSHomeDirectory was used
because it's what is mentioned in the Apple documentation I've seen
regarding the App Sandbox.
A sandboxed Java app definitely
needs to know about the app's Container directory (and even whether it's
actually being run sandboxed or not), but redefining user.home doesn't seem
like the right solution. Having AppBundler (or even the JRE) provide that
information via special properties feels better from my developer's
perspective.
Adding an additional special property may or may not fly, but I can look
into it.
Thanks,
-Brent
On Fri, Sep 6, 2013 at 6:18 PM, David DeHaven <david.deha...@oracle.com>wrote:
As someone with a Java app in the Mac App Store (MAS), I would like to
vote against this change.
It is still important to know the user's actual home directory
(/Users/<username>) even if the app is running in the sandbox. Using the
entitlement, com.apple.security.files.user-selected.read-write, we can
still write to user selected directories (such as ~/Documents). So
changing the user.home property to point to somewhere in the app's
Container would make it more difficult to get the actual home directory and
thus, other directories that the end-user is familiar with. I also think
this change would lead to more developer confusion and make application
code more complicated.
I don't know all what the user.home property is used for in the JDK
itself, but concerns about the MAS sandbox would be, IMHO, better handled
using special Mac/MAS only properties, such as those setup by
infinitekind's Appbundler fork on bitbucket:
https://bitbucket.org/infinitekind/appbundler
Nick
I'm sure Brent wants to do the right thing here and maybe this needs
some input from the Apple or other Mac-savvy folks as to whether sandboxed
apps are really supposed to know about the actual user's home directory.
FWIW, the original recommendaiton to switch to NSHomeDirectory came from
Scott Kovatch when he was working on Application Bundler. It's very
possible that things have changed since then.
I haven't had a chance to look at the changes yet, so this may be a bit
premature...
Using NSHomeDirectory is the CORRECT behavior, whether the app is
sandboxed or not (that extends to ALL apps, not just Java based).
If the application needs to access Documents, Music, Movies, etc then
those entitlements need to be added. Additionally, even if sandboxed an
application can open documents in any folder the user has access to as long
as the standard file chooser is used (which I believe we already do), the
app will be granted (indirect) access to the selected file(s).
-DrD-
