Hi, Sean.
The correct mailing list for discussion of such issues is: 2d-dev (cc).
----- srei...@seanreilly.com 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
