This problem is occurring because of the 32bit compiled JNA library in the jna.jar.

See http://blog.avisi.nl/2011/12/28/mac-os-x-firewall-accept-incoming-network-connections/ for a workaround

We need to test dev-57 on OSX with a Single User License key and the firewall enabled.

I can replicate this on dev-59

see attached

According to TW @ JNA :

"libjnidispatch.jnilib is a universal binary with three targets; you can use the "file" command to get that information."

"You need to put libjnidispatch.jnilib somewhere in your .app folder and ensure it's in DYLD_LIBRARY_PATH (or some equivalent) when the VM launches.  If JNA can't find it on the system library load path, it unpacks it from jna.jar on each run (into java.io.tmpdir), which is why you're prompted for permissions each time."

I am now including libinidispatch.jnilib in $JAVAROOT, and included in info.plist :

        <key>DYLD_LIBRARY_PATH</key>
        <string>$JAVAROOT</string>

But we still seem to have the problem.

On your e-mail notes, you suggested renaming/removing the libjnidispatch.jnilib file from ADS' Contents/Resources/Java would make the Firewall stop prompting every time about allowing income connections, but this trick doesn't work for me. It doesn't work even if I remove all the dynamic library files from this folder.

I think this issue is triggered by the fact that Firewall identifies the app as "Aqua Data Studio.app", but the app launched is actually "JavaApplicationStub" and hence name matching (under firewall rules) fails next time ADS is launched.

One workaround is to force JVM to use 32bit mode by adding these entries in Info.plist ( just under the <key>Java</key> <dict>  tree ):

<key>JVMArchs</key>
<array>
<string>i386</string>
</array>

In this case I think Firewall identifies ADS as "JavaApplicationStub" , therefore the app is whitelisted and never prompts to allow incoming connections. The license key collision mechanism is still working in this case.

I noticed there is one 64bit dynamic library ( libmesa64.jnilib ) which I am not sure when it is used (chart rendering works fine even if JVM is forced to use 32-bit mode; maybe this enforcement affects only Java bytecode, not the dynamic libraries).

More info about the workaround and firewall name matching issue can be found here: http://forum.vuze.com/thread.jspa?threadID=93338 .

The workaround works also if the JVMArchs array contains both "i386" and "x86_64". As "i386" is the first array element, the os.arch Java property has the value "i386".