From brent.christian at oracle.com Tue Mar 1 21:16:47 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 1 Mar 2016 13:16:47 -0800 Subject: RFR 8148187 : Remove OS X-specific com.apple.concurrent package Message-ID: <56D606BF.4080603@oracle.com> Hi, A number of internal APIs were carried over into the JDK with the Apple port. Among them was com.apple.concurrent.Dispatch. Supportedness has always been murky here, but Jigsaw necessitates a firmer stance. Some of these APIs have already been removed from JDK 9 [1], some will be supplanted by new, supported APIs [2]. As already discussed in [3] and [4], com.apple.concurrent.Dispatch is no longer in use, as far as we've been able to find. com.apple.concurrent.Dispatch and its supporting code should be removed from JDK 9. It turns out this opens the door for a little module pruning as well. com.applet.concurrent makes up the bulk of the jdk.deploy.osx module. All that's left is native code for libosx, a library relied on by com.apple.eio.FileManager in the java.desktop module. By moving libosx over to java.desktop, we are able to do away with the jdk.deploy.osx module altogether. For your review is a webrev of this change: http://cr.openjdk.java.net/~bchristi/8148187/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8148187 Automated build+test runs look fine. If, in the future, there is desire for an ExecutorService backed by the native platform (as com.apple.concurrent.Dispatch does for libdispatch on OS X), such a feature could be proposed. Thanks, -Brent 1. "Remove apple script engine code in jdk repository" https://bugs.openjdk.java.net/browse/JDK-8143404 2. JEP 272 : "Platform-Specific Desktop Features" https://bugs.openjdk.java.net/browse/JDK-8048731 3. http://mail.openjdk.java.net/pipermail/macosx-port-dev/2015-May/006934.html 4. http://mail.openjdk.java.net/pipermail/macosx-port-dev/2015-September/006968.html From mandy.chung at oracle.com Wed Mar 2 04:36:24 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 1 Mar 2016 20:36:24 -0800 Subject: RFR 8148187 : Remove OS X-specific com.apple.concurrent package In-Reply-To: <56D606BF.4080603@oracle.com> References: <56D606BF.4080603@oracle.com> Message-ID: <66D9A294-73D2-49FB-9AFD-31D57077585B@oracle.com> > On Mar 1, 2016, at 1:16 PM, Brent Christian wrote: > > Hi, > > A number of internal APIs were carried over into the JDK with the Apple port. Among them was com.apple.concurrent.Dispatch. > > Supportedness has always been murky here, but Jigsaw necessitates a firmer stance. Some of these APIs have already been removed from JDK 9 [1], some will be supplanted by new, supported APIs [2]. > > As already discussed in [3] and [4], com.apple.concurrent.Dispatch is no longer in use, as far as we've been able to find. com.apple.concurrent.Dispatch and its supporting code should be removed from JDK 9. > > It turns out this opens the door for a little module pruning as well. com.applet.concurrent makes up the bulk of the jdk.deploy.osx module. All that's left is native code for libosx, a library relied on by com.apple.eio.FileManager in the java.desktop module. By moving libosx over to java.desktop, we are able to do away with the jdk.deploy.osx module altogether. > > For your review is a webrev of this change: > http://cr.openjdk.java.net/~bchristi/8148187/webrev.01/ > It?s good to see jdk.deploy.osx finally going away. The patch looks fine. common/bin/unshuffle_list.txt should be adjusted as well (while this file looks like not being kept up-to-date though) No need to submit a new webrev. Mandy From erik.joelsson at oracle.com Wed Mar 2 07:50:46 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 2 Mar 2016 08:50:46 +0100 Subject: RFR 8148187 : Remove OS X-specific com.apple.concurrent package In-Reply-To: <56D606BF.4080603@oracle.com> References: <56D606BF.4080603@oracle.com> Message-ID: <56D69B56.2000604@oracle.com> Hello Brent, The build changes look pretty good. Just one nit, in the new LibosxLibraries.gmk, please remove the "include LibCommon.gmk" as that is now handled by Lib-java.desktop.gmk. /Erik On 2016-03-01 22:16, Brent Christian wrote: > Hi, > > A number of internal APIs were carried over into the JDK with the > Apple port. Among them was com.apple.concurrent.Dispatch. > > Supportedness has always been murky here, but Jigsaw necessitates a > firmer stance. Some of these APIs have already been removed from JDK > 9 [1], some will be supplanted by new, supported APIs [2]. > > As already discussed in [3] and [4], com.apple.concurrent.Dispatch is > no longer in use, as far as we've been able to find. > com.apple.concurrent.Dispatch and its supporting code should be > removed from JDK 9. > > It turns out this opens the door for a little module pruning as well. > com.applet.concurrent makes up the bulk of the jdk.deploy.osx module. > All that's left is native code for libosx, a library relied on by > com.apple.eio.FileManager in the java.desktop module. By moving > libosx over to java.desktop, we are able to do away with the > jdk.deploy.osx module altogether. > > For your review is a webrev of this change: > http://cr.openjdk.java.net/~bchristi/8148187/webrev.01/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8148187 > > > Automated build+test runs look fine. > > If, in the future, there is desire for an ExecutorService backed by > the native platform (as com.apple.concurrent.Dispatch does for > libdispatch on OS X), such a feature could be proposed. > > Thanks, > -Brent > > 1. "Remove apple script engine code in jdk repository" > https://bugs.openjdk.java.net/browse/JDK-8143404 > > 2. JEP 272 : "Platform-Specific Desktop Features" > https://bugs.openjdk.java.net/browse/JDK-8048731 > > 3. > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2015-May/006934.html > > 4. > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2015-September/006968.html > From Alan.Bateman at oracle.com Wed Mar 2 08:51:19 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Mar 2016 08:51:19 +0000 Subject: RFR 8148187 : Remove OS X-specific com.apple.concurrent package In-Reply-To: <56D606BF.4080603@oracle.com> References: <56D606BF.4080603@oracle.com> Message-ID: <56D6A987.6040506@oracle.com> On 01/03/2016 21:16, Brent Christian wrote: > > For your review is a webrev of this change: > http://cr.openjdk.java.net/~bchristi/8148187/webrev.01/ This looks good to me, in particular the move of FileManager.m into the right source tree as it was just wrong for that to be in jdk.deploy.osx when the com.apple.eio classes are in the java.desktop module. -Alan. From krueger at lesspain.de Sat Mar 5 13:15:29 2016 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Sat, 5 Mar 2016 14:15:29 +0100 Subject: Setting created timestamp of files using BasicFileAttributeView Message-ID: Hi, could anyone tell me if setting the created time of a file via BasicFileAttributeView is not supported on OSX? I tried using the following code snippet: BasicFileAttributeView attributes = Files.getFileAttributeView(Paths.get(file.getAbsolutePath()), BasicFileAttributeView.class); FileTime time = FileTime.fromMillis(someNewTimeInMillis); attributes.setTimes(time, time, time); Finder displays last modified and last opened (i.e. last accessed, I assume) as the value specified by someNewTimeInMillis but created remains at the old value. Is this simply not supported on OSX and I have to use a native call to do this? Thanks in advance for any hint. Robert From mik3hall at gmail.com Sat Mar 5 14:23:34 2016 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 5 Mar 2016 08:23:34 -0600 Subject: Setting created timestamp of files using BasicFileAttributeView In-Reply-To: References: Message-ID: <23B10992-232B-46AD-A212-86FC0FD8E908@gmail.com> > On Mar 5, 2016, at 7:15 AM, Robert Kr?ger wrote: > > Hi, > > could anyone tell me if setting the created time of a file via > BasicFileAttributeView is not supported on OSX? I tried using the following > code snippet: > > BasicFileAttributeView attributes = > Files.getFileAttributeView(Paths.get(file.getAbsolutePath()), > BasicFileAttributeView.class); > FileTime time = FileTime.fromMillis(someNewTimeInMillis); > attributes.setTimes(time, time, time); > > Finder displays last modified and last opened (i.e. last accessed, I > assume) as the value specified by someNewTimeInMillis but created remains > at the old value. > > Is this simply not supported on OSX and I have to use a native call to do > this? This?, https://stackoverflow.com/questions/9198184/setting-file-creation-timestamp-in-java seems to suggest that File.setLastModified will accomplish what you wan on OS Xt. You would probably want to check on the nio dev list to see if this is considered a bug or expected behavior on OS X. If default nio file attributes don?t work and you really want that approach for what you are doing, then before getting into native yourself you could take a look at my trz project? https://github.com/mik3hall/trz It has a nio OS X specific filesystem. A lot of what actually works is exposing different native file api?s as attributes. One of them may already support this, I don?t remember. If you find a native api that does support this and my implementation of it?s attributes does not, let me know, I?ll add it. Michael Hall From swpalmer at gmail.com Sat Mar 5 20:35:43 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 5 Mar 2016 15:35:43 -0500 Subject: Setting created timestamp of files using BasicFileAttributeView In-Reply-To: References: Message-ID: If it can be accomplished by native code then I would file a bug against the JDK as that is clearly where such native code belongs. Scott > On Mar 5, 2016, at 8:15 AM, Robert Kr?ger wrote: > > Hi, > > could anyone tell me if setting the created time of a file via > BasicFileAttributeView is not supported on OSX? I tried using the following > code snippet: > > BasicFileAttributeView attributes = > Files.getFileAttributeView(Paths.get(file.getAbsolutePath()), > BasicFileAttributeView.class); > FileTime time = FileTime.fromMillis(someNewTimeInMillis); > attributes.setTimes(time, time, time); > > Finder displays last modified and last opened (i.e. last accessed, I > assume) as the value specified by someNewTimeInMillis but created remains > at the old value. > > Is this simply not supported on OSX and I have to use a native call to do > this? > > Thanks in advance for any hint. > > Robert From mik3hall at gmail.com Sun Mar 6 12:26:32 2016 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 6 Mar 2016 06:26:32 -0600 Subject: Setting created timestamp of files using BasicFileAttributeView In-Reply-To: References: <23B10992-232B-46AD-A212-86FC0FD8E908@gmail.com> Message-ID: <0A45DCB8-6681-47DF-AE94-8B2A4A6B22E3@gmail.com> > On Mar 6, 2016, at 5:28 AM, Robert Kr?ger wrote: > > > > On Sat, Mar 5, 2016 at 3:23 PM, Michael Hall > wrote: >> On Mar 5, 2016, at 7:15 AM, Robert Kr?ger > wrote: >> >> > > This?, > https://stackoverflow.com/questions/9198184/setting-file-creation-timestamp-in-java > seems to suggest that File.setLastModified will accomplish what you wan on OS Xt. > > No, that's what I started with and it does what it's documented to do. I?m assuming ?what it?s documented to do? means it changes something other than finder creation date/time. Maybe the stack overflow link I posted wasn?t concerned with changing Finder related. These suggest using the ?touch? or ?SetFile? commands could accomplish this... https://medium.com/@danilosapad/how-to-change-a-file-s-last-modified-and-creation-dates-on-mac-os-x-494f8f76cdf4#.y8qxzwtgg https://apple.stackexchange.com/questions/99536/changing-creation-date-of-a-file you could probably runtime exec those from java easily enough. Changing even from native seems like it could be a little tricky for some reason. At least this link suggests it might be... https://stackoverflow.com/questions/6905503/setting-nsfilecreationdate-has-no-effect My trz code does support some cocoa/NSFileManager type attributes? https://github.com/mik3hall/trz/blob/master/src/us/hall/trz/osx/test/MacAttributesTest.java shows junit tests of some of the api?s supported. For Cocoa it has this. @Test public void testCocoa() { try { File f = new File("build.xml"); Path p = f.toPath(); Map attrs = Files.readAttributes(p,"mac_cocoa:*"); assertEquals(17,attrs.size()); assertFalse(((Boolean)Files.getAttribute(p,"mac_cocoa:NSFileBusy")).booleanValue()); assertEquals(Files.size(p),((Long)Files.getAttribute(p,"mac_cocoa:NSFileSize")).longValue()); attrs = Files.readAttributes(p,"mac_cocoa:NSFileModificationDate,mac_cocoa:NSFilePosixPermissions"); assertEquals(2,attrs.size()); } catch (IOException ioex) { fail(ioex.toString()); } } Updating may not be supported. But could be added if you or anyone else want to use it. I didn?t want my first feedback on the code to be that someone tried it and something got messed up on their machine. ?Hey, I tried your code and it turned all the files orange?. (I think I did include that possibility for FinderInfo though? Files.setAttribute(p, "mac_finder:label", "orange?); it was just kind of fun). This would do all the native for you and allow you to do what you want in the nio.2 way. Assuming I can get it to work. Despite the last stack overflow post it doesn?t seem like it should be all that difficult. Michael Hall From krueger at lesspain.de Sun Mar 6 13:01:19 2016 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Sun, 6 Mar 2016 14:01:19 +0100 Subject: Setting created timestamp of files using BasicFileAttributeView In-Reply-To: <0A45DCB8-6681-47DF-AE94-8B2A4A6B22E3@gmail.com> References: <23B10992-232B-46AD-A212-86FC0FD8E908@gmail.com> <0A45DCB8-6681-47DF-AE94-8B2A4A6B22E3@gmail.com> Message-ID: sorry, I replied to Scott's mail not using "reply-all" (this ml-setting sucks bigtime), so you only git half of the information. On Sun, Mar 6, 2016 at 1:26 PM, Michael Hall wrote: > On Mar 6, 2016, at 5:28 AM, Robert Kr?ger wrote: > > > > On Sat, Mar 5, 2016 at 3:23 PM, Michael Hall wrote: > >> On Mar 5, 2016, at 7:15 AM, Robert Kr?ger wrote: >> >> >> >> This?, >> >> https://stackoverflow.com/questions/9198184/setting-file-creation-timestamp-in-java >> seems to suggest that File.setLastModified will accomplish what you wan >> on OS Xt. >> > > No, that's what I started with and it does what it's documented to do. > > > I?m assuming ?what it?s documented to do? means it changes something other > than finder creation date/time. > meaning it only changes last modified and not created. When I set creation date using a cocoa call (NSFileManager:setAttributes:ofItemAtPath:error:) mapped to java, behaviour is as expected and creation date is changed. I filed a jdk bug report (Review ID: JI-9031479). > > Maybe the stack overflow link I posted wasn?t concerned with changing > Finder related. > These suggest using the ?touch? or ?SetFile? commands could accomplish > this... > > https://medium.com/@danilosapad/how-to-change-a-file-s-last-modified-and-creation-dates-on-mac-os-x-494f8f76cdf4#.y8qxzwtgg > > https://apple.stackexchange.com/questions/99536/changing-creation-date-of-a-file > you could probably runtime exec those from java easily enough. > > Changing even from native seems like it could be a little tricky for some > reason. At least this link suggests it might be... > > https://stackoverflow.com/questions/6905503/setting-nsfilecreationdate-has-no-effect > > My trz code does support some cocoa/NSFileManager type attributes? > > https://github.com/mik3hall/trz/blob/master/src/us/hall/trz/osx/test/MacAttributesTest.java > shows junit tests of some of the api?s supported. > For Cocoa it has this. > > @Test > public void testCocoa() { > try { > File f = new File("build.xml"); > Path p = f.toPath(); > Map attrs = Files.readAttributes(p,"mac_cocoa:*"); > assertEquals(17,attrs.size()); > > assertFalse(((Boolean)Files.getAttribute(p,"mac_cocoa:NSFileBusy")).booleanValue()); > > assertEquals(Files.size(p),((Long)Files.getAttribute(p,"mac_cocoa:NSFileSize")).longValue()); > > attrs = Files.readAttributes(p,"mac_cocoa:NSFileModificationDate,mac_cocoa:NSFilePosixPermissions"); > assertEquals(2,attrs.size()); > } > catch (IOException ioex) { fail(ioex.toString()); } > } > > Updating may not be supported. But could be added if you or anyone else > want to use it. I didn?t want > see above. It is supported by just creating a mutable dictionary with the old values, mofiying the key for created date and then setting those attributes. > my first feedback on the code to be that someone tried it and something > got messed up on their machine. ?Hey, I tried your code and it turned all > the files orange?. (I think I did include that possibility for FinderInfo > though? > Files.setAttribute(p, "mac_finder:label", "orange?); > it was just kind of fun). > This would do all the native for you and allow you to do what you want in > the nio.2 way. Assuming I can get it to work. Despite the last stack > overflow post it doesn?t seem like it should be all that difficult. > > > Robert From mik3hall at gmail.com Sun Mar 6 13:18:57 2016 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 6 Mar 2016 07:18:57 -0600 Subject: Setting created timestamp of files using BasicFileAttributeView In-Reply-To: References: <23B10992-232B-46AD-A212-86FC0FD8E908@gmail.com> <0A45DCB8-6681-47DF-AE94-8B2A4A6B22E3@gmail.com> Message-ID: <56F22367-BF8B-45B6-B617-0B5F0BDC37BE@gmail.com> > On Mar 6, 2016, at 7:01 AM, Robert Kr?ger wrote: > When I set creation date using a cocoa call (NSFileManager:setAttributes:ofItemAtPath:error:) mapped to java, behaviour is as expected and creation date is changed. I filed a jdk bug report (Review ID: JI-9031479). OK, should be a long term fix unless they decide for some reason changing this should not be allowed and that is for some reason the ?expected behavior?. I think one of the posts I had a url on said it doesn?t work on Linux systems either. I could add it to mine based on your code, or you could I guess, the source is on github. As I remember you would need to specify my OS X specific filesystem(provider) as a jvm launch parameter. It is the same as the usual I think (falling through to the default filesystem(provider) for about everything except adding the additional OS X file attribute views. Again a lot of the api?s don?t support update as I was sort of waiting for interest on the read only attributes, which hasn?t yet really been indicated, before making the code ?more serious?. It does have a currently non-functioning WatchService, so if you need one of those that works it might not be for you. Although, I may of had a property switch or something that let you fallback to the default there as well. It?s been a while for most of this, I don?t remember. Michael Hall From mik3hall at gmail.com Tue Mar 8 10:00:03 2016 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 8 Mar 2016 04:00:03 -0600 Subject: nio.2 file attributes for OS X Message-ID: <2AE48AAD-7BCF-4891-ADF9-930D4D87AE36@gmail.com> fwiw, After a recent discussion I have updated my github trz project, the ant file now at least includes something to compile the java, which after a couple tweaks it did last night successfully. Still a little thrown together so if anyone tries it and has any problems please let me know. It must of been very thrown together last time, it was a mess. In the interest of ?eating my own dog food? I have just added the jar and dylib to my HalfPipe app. I intend to do some things with external files and I think the Mac specific file attributes in trz could be useful. The app does still launch so changing the default FileSystemProvider appears to cause no initial problems. For about everything except additional OS X specific nio.2 file attributes it should fall back to the jvm provided default FileSystemProvider. https://github.com/mik3hall/trz https://www195.pair.com/mik3hall/halfpipe.dmg Although HalfPipe with the nio.2 related hasn?t been uploaded yet. Michael Hall From mik3hall at gmail.com Fri Mar 11 01:51:18 2016 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 10 Mar 2016 19:51:18 -0600 Subject: Application Support directory to classpath Message-ID: <8DD3CD85-9827-4738-9C68-901F917E59FE@gmail.com> I am trying to add some support for my application updating external files. Appstore is not necessarily a major concern, but I wouldn?t want to eliminate it as a possibility for no good reason by doing something unnecessarily violating some app store constraint. In some quick browsing I saw no real better choice to place the data than using the Application Support directory. If there is a better way of handling that now please let me know. The problem is that the Application Support directory is a user one. /Users//Library/Application Support/ The application has configuration property files that refer to these files by name. I can get around having to provide full path in these property files by only providing filename and having it in class path. The configuration code looks like it will then check for the file first in the ?current working directory? (user.dir?). Then checking for it in class path. Fine, unless I want the application to be able to update the file. Class path entries are all internal to the application bundle which in the Application directory I don?t think is supposed to be updatable. The idea I just had was ok make some thing like Application Support//classes an entry in class path via an URLClassLoader. I am considering something similar for plugin code anyhow,jars,property files, everything going into Application Support. Does this seem like it would violate App Store/sandboxing or anything like that? Michael Hall From hs at tagtraum.com Fri Mar 11 07:23:02 2016 From: hs at tagtraum.com (Hendrik Schreiber) Date: Fri, 11 Mar 2016 08:23:02 +0100 Subject: Application Support directory to classpath In-Reply-To: <8DD3CD85-9827-4738-9C68-901F917E59FE@gmail.com> References: <8DD3CD85-9827-4738-9C68-901F917E59FE@gmail.com> Message-ID: Hey Michael, > On Mar 11, 2016, at 02:51, Michael Hall wrote: > > I am trying to add some support for my application updating external files. Appstore is not necessarily a major concern, but I wouldn?t want to eliminate it as a possibility for no good reason by doing something unnecessarily violating some app store constraint. In some quick browsing I saw no real better choice to place the data than using the Application Support directory. If there is a better way of handling that now please let me know. When your app is sandboxed, it does not have access to Application Support. Instead, it has its own ?container?. Read more about this at https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW15 If you want to first get started and worry about sandboxing later, Application Support is IMHO the right place for this kind of thing. To migrate later, take a look at https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/MigratingALegacyApp/MigratingAnAppToASandbox.html#//apple_ref/doc/uid/TP40011183-CH6-SW1 To find the Application Support directory, you can use import com.apple.eio.FileManager; private static final int kApplicationSupportFolder = 0x61737570; // asup String folder = FileManager.findFolder(FileManager.kUserDomain, kApplicationSupportFolder); This will at least work as long as com.apple.eio.FileManager still exists (not sure, whether this will eventually go away with JDK9). Whether System.getProperty("user.home?) will return the container directory for a sandboxed app is an interesting question that I don?t know the answer to. The Objective-C docs recommend to use https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Functions/index.html#//apple_ref/c/func/NSHomeDirectory to get it. Cheers, -hendrik From mik3hall at gmail.com Fri Mar 11 09:47:32 2016 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 11 Mar 2016 03:47:32 -0600 Subject: Application Support directory to classpath In-Reply-To: References: <8DD3CD85-9827-4738-9C68-901F917E59FE@gmail.com> Message-ID: <2FAB03AD-888E-4595-9759-6D5EA075A494@gmail.com> > On Mar 11, 2016, at 1:23 AM, Hendrik Schreiber wrote: > > Hey Michael, > >> On Mar 11, 2016, at 02:51, Michael Hall wrote: >> >> I am trying to add some support for my application updating external files. Appstore is not necessarily a major concern, but I wouldn?t want to eliminate it as a possibility for no good reason by doing something unnecessarily violating some app store constraint. In some quick browsing I saw no real better choice to place the data than using the Application Support directory. If there is a better way of handling that now please let me know. > > > When your app is sandboxed, it does not have access to Application Support. > Instead, it has its own ?container?. Read more about this at https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW15 Thanks, my understanding of this should be better. I?ll take a look at this. > To migrate later, take a look at Thanks again. > To find the Application Support directory, you can use > > import com.apple.eio.FileManager; I do have code like this. So for one thing it was good to see recently that the java 9 effort has found a good home for FileManager going forward. The problem is it?s not possible to reflect code like this into a static properties file. So for the code I?m looking at I was considering the approach of just supplying a file name and not a path, then if I follow the code right it will fallback to looking for the filename in class path. So if I get it into a Application Support directory that is in class path, it should work. > Whether System.getProperty("user.home?) will return the container directory for a sandboxed app is an interesting question that I don?t know the answer to. The Objective-C docs recommend to use https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Functions/index.html#//apple_ref/c/func/NSHomeDirectory to get it. user.home I generally don?t use. Though, I am pretty used to it always being /Users/. user.dir has moved around a little bit over the years for java. Given sandboxing or App Store is not a concern then either would probably be ok to use. More properly these days, if you do have sandboxing or App Store concerns I have assumed you should not count on properties like this to access external files anymore, period. Maybe someone else can answer the question of whether or not this has been considered for sandboxed java applications so that you actually do get something different for these properties that is usable? Michael Hall From mik3hall at gmail.com Sat Mar 12 11:00:58 2016 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 12 Mar 2016 05:00:58 -0600 Subject: Application Support directory to classpath In-Reply-To: <2FAB03AD-888E-4595-9759-6D5EA075A494@gmail.com> References: <8DD3CD85-9827-4738-9C68-901F917E59FE@gmail.com> <2FAB03AD-888E-4595-9759-6D5EA075A494@gmail.com> Message-ID: <26486574-FCEC-4C08-A35E-5F6AD366F12F@gmail.com> > On Mar 11, 2016, at 3:47 AM, Michael Hall wrote: > >> > > Maybe someone else can answer the question of whether or not this has been considered for sandboxed java applications so that you actually do get something different for these properties that is usable? Given no one has tried answering this I would either assume sandboxed settings aren?t different or people who know if they are different aren?t following the list anymore. It doesn?t seem all that bad an idea to me. With applications getting more complex having different possible settings for some of these properties could make sense. Say signed and sandboxed versus not MAS targeted could have different user.dir settings. Meanwhile, since I am not currently MAS targeted I will see what I can do with Application Support, although that is really not all that different from using user.home/user.dir. javapackager user.dir I think had user.dir set to the app path itself. Useful for read access of your own app files, but not for storing data assuming you are in the Application directory with no write permissions. Again since the Apple jvm?s (user.dir was always the app's directory as I remember) I think this setting has changed a couple of times. javapackager may of changed again I vaguely remember. My last couple tries with javapackager didn?t successfully get me valid application bundles at all, but it wasn?t anything I needed critically. I will take a look at your links. Thanks. Michael Hall From hs at tagtraum.com Sat Mar 12 11:18:51 2016 From: hs at tagtraum.com (Hendrik Schreiber) Date: Sat, 12 Mar 2016 12:18:51 +0100 Subject: Application Support directory to classpath In-Reply-To: <26486574-FCEC-4C08-A35E-5F6AD366F12F@gmail.com> References: <8DD3CD85-9827-4738-9C68-901F917E59FE@gmail.com> <2FAB03AD-888E-4595-9759-6D5EA075A494@gmail.com> <26486574-FCEC-4C08-A35E-5F6AD366F12F@gmail.com> Message-ID: Hey Michael, FWIW, I have been using https://bitbucket.org/infinitekind/appbundler as packager/launcher for a while now. It passes a couple of additional environment variables to the JVM: ? LibraryDirectory ? DocumentsDirectory ? CachesDirectory ? ApplicationSupportDirectory ? SandboxEnabled (the String true or false) Not sure what javapackager does. Perhaps this is helpful for you. -hendrik > On Mar 12, 2016, at 12:00, Michael Hall wrote: > >> On Mar 11, 2016, at 3:47 AM, Michael Hall wrote: >> >>> >> >> Maybe someone else can answer the question of whether or not this has been considered for sandboxed java applications so that you actually do get something different for these properties that is usable? > > Given no one has tried answering this I would either assume sandboxed settings aren?t different or people who know if they are different aren?t following the list anymore. > > It doesn?t seem all that bad an idea to me. With applications getting more complex having different possible settings for some of these properties could make sense. Say signed and sandboxed versus not MAS targeted could have different user.dir settings. > > Meanwhile, since I am not currently MAS targeted I will see what I can do with Application Support, although that is really not all that different from using user.home/user.dir. > > javapackager user.dir I think had user.dir set to the app path itself. Useful for read access of your own app files, but not for storing data assuming you are in the Application directory with no write permissions. Again since the Apple jvm?s (user.dir was always the app's directory as I remember) I think this setting has changed a couple of times. javapackager may of changed again I vaguely remember. > > My last couple tries with javapackager didn?t successfully get me valid application bundles at all, but it wasn?t anything I needed critically. > > I will take a look at your links. > > Thanks. > > Michael Hall > > > From mik3hall at gmail.com Sat Mar 12 11:29:29 2016 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 12 Mar 2016 05:29:29 -0600 Subject: Application Support directory to classpath In-Reply-To: References: <8DD3CD85-9827-4738-9C68-901F917E59FE@gmail.com> <2FAB03AD-888E-4595-9759-6D5EA075A494@gmail.com> <26486574-FCEC-4C08-A35E-5F6AD366F12F@gmail.com> Message-ID: <517474E7-2FE5-4409-86E7-20EFB753A8D4@gmail.com> > Not sure what javapackager does. Perhaps this is helpful for you. javapackager is the current Oracle supported application builder. It automatically handles the signing related for sandboxed. The infinitekind app bundler fork might be worth a look as well though. Michael Hall