Libreoffice Java x64 connection through UNO
sbergman at redhat.com
Wed Apr 11 06:16:31 PDT 2012
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
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.
More information about the LibreOffice