printing from the mac sandbox

[Philip Race]

This list should really be archived as the port  project is over .. 
macos is just another one of the JDK desktop platforms.
So you should re-post this to 2d-dev at openjdk.java.net which is the right 
place to consider a patch too.
And perhaps file a bug at java.com since I don't know of any bug report 
to this effect.

-phil.

On 6/1/17, 3:17 AM, Sean Reilly wrote:
> There seems to be a big printing problem using recent JDKs when running within the macOS sandbox as of 10.12.4.
>
> Looking at the jdk8 sources, CUPSfuncs.c seems to ignore the connection point provided by the system CUPS libraries if it returns a reference to a unix domain socket address:
>
>    // Is this a local domain socket?
>    if (strncmp(server, "/", 1) == 0) {
>      cServer = JNU_NewStringPlatform(env, "localhost");
>    } else {
>      cServer = JNU_NewStringPlatform(env, server);
>    }
>
> This causes the CUPSPrinter.java and CUPSfunc code to connect to localhost via TCP port 631 instead of the unix domain socket which should be where it connects.
>
> MacOS Sierra 10.12.4 had some security related changes to the sandbox which explicitly blocks connections from a sandboxed app to TCP localhost:631.  This blockage (or at least a very long delay) applies even if network-client, network-server, and print entitlements are set for the app, which means there's no way around the problem.
>
> I've talked to Apple DTS and they aren't inclined to allow the connection to localhost:631, even if the network-client and print entitlements are enabled.
>
> As you can imagine, not being able to print from a desktop app is pretty bad for business.
>
> My questions are:
>   1) Is anyone at Oracle aware of and working on this?
>
>   2) Is there a reason not to use the unix domain socket connection? The connection details seem to be encapsulated within the libcups code so I don't see why the java level needs to override the result returned by the call to `cupsServer`
>
>   3) Is a patch that uses the unix domain socket likely to be accepted, and if so, where should it be sent?
>
>   4) Is there a better mailing list for this discussion?
>
> Thanks,
> Sean
>