Re: Libreoffice Java x64 connection through UNO

On 04/11/2012 02:04 PM, Tor Lillqvist wrote:
> > The one problem is that UNO "named pipe" (i.e., --accept=pipe,name=foo;urp)
> > communication, even from within a pure Java environment, needs some native
> > code (jpipe JNI library) which obviously needs to be available in the format
> > of the JVM process's architecture.
>
> OK. So would it be feasible to build this jpipe JNI library also as
> 64-bit code, even if LO as such is built as 32-bit code? (We already
> have some mechanisms for stuff like this in place, to build the
> Explorer extension code also as 64-bit.) (Whether that actually works
> is another question, though, there has been bug reports about the
> Explorer extension recently...)
>
> The source for this jpipe library (or actually, for jpipx.dll, which
> is wrapped by a thin jpipe.dll on Windows) is
> jurt/source/pipe/com_sun_star_lib_connections_pipe_PipeConnection.c, I
> assume?

Should be doable.  Question is if it is worth it.  There might be 
additional native code involved that I forgot about.  I would first 
check whether using TCP sockets instead of "named pipes" for UNO 
communication solves the OP's problem.  An alternative would be to 
invest work in a 64 bit Windows LO.  (Another alternative might be for 
the OP to use 32 bit Java on Windows?)  On the con side, every addition 
makes the fat code base even fatter.

> I see that it does #include "osl/security.h", and that jpipx.dll
> imports from sal3.dll a handful of osl_ and rtl_ functions. So those
> would have to be built as 64-bit code, too. Still, not rocket science.
> (I would even say that it would be best to just copy-paste those
> functions into the com_sun_star_lib_connections_pipe_PipeConnection.c,
> and not have any separate wrapper dll at all, just a jpipe.dll that
> doesn't import sal3.dll.

I would prefer keeping the wrapper library here instead of duplicating code.

Stephan