Libreoffice and Java

users
#21

Yes, that is correct. Would still be broken if you don't also clean up the javasettings .xml configuration file.

Additionally, for folks on a 64-bit build of Windows, if you install both a 32-bit and a 64-bit JRE, you need to watch which JRE gets called with LibreOffice. Oracle installers place copies of latest installed executable into the C:\Windows\system32 (the 64-bit executables), and also in C:\Windows\SysWOW64 (for the 32-bit executables).

They are copied from the respective installation directories of the JREs, but with a default installation these executables will be "found" before any other instance referred by the PATH environment, so they are the JREs used by default--and that can cause problems if not expected (as can issues with location of a MS C++ runtime not being present with the Java virtual machine libraries).

To convince yourself, leave the C:\Windows copies intact and run a Command Window, and then execute "java -version", if you have the 64-bit JRE installed and you will see the version labeled as 64-bit build--not the 32-bit. And that also seems to causes problems for LibreoOffice which on Windows remains 32-bit.

To precisely control which JRE is used, you have to remove the executables from the system32 and SysWOW64 directories, and then establish a specific location on the PATH for them. Can be anywhere in the PATH environment variable, but for security after the Windows OS components. Also by convention you can create a JAVA_HOME environment variable and use a "%JAVA_HOME%\bin" reference in the PATH. Very useful (and the norm in Linux) in that you can programmatically change the JAVA_HOME variable when you need a different JRE (either the version or use of a 64-bit build).

Stuart

#22

Yes, that is correct. Would still be broken if you don't also clean
upthe javasettings .xml configuration file.

This makes no sense.

Is there some reason that the install routine can't automate this?

I just don't see thousands (or millions) of users having to do this manually.

#23

Well Bob... if you tell this list what version of LO you are talking
about perhaps we/they can assist? Or should we all go testing in 3.5.xyz
or 3.6.xyz?

I certainly don't mind testing, but given that it is Windows 7 you are
referring to, it would be helpful if you tell us the version you are
talking about. (Help|About LibreOffice usually works well).

#24

Tanstaafl wrote

This makes no sense.

Is there some reason that the install routine can't automate this?

I just don't see thousands (or millions) of users having to do this
manually.

Only you and a couple of others. You must not think that this is a general
problem that has been overlooked by the testers.

1) Java is not required to use this software. Just disable Java and use the
remaining 98% of it.
2) LibreOffice for Windows is a 32 bit application -- always. Any Java
component integrated into this software requires a 32 bit Java runtime.
3) The 2% of Java dependent features should work with any recent Java
version 6 or 7 (again: 32bit Java on Windows). The developers have no
influence on third party extensions though. Third party extensions may be
incompatible with Java7.
4) There is absolutely nothing wrong with Java 6. It is still maintained and
fully supported.
5) You can have as many Java versions on the same machine as required to run
your more or less antiquated Java applications, libraries, applets and
stuff. Regarding this office suite, just point your office to the latest
Java6-32 and all will be fine with any combination of LibreOffice,
extensions, wizards and Java databases.

I run LibreOffice 3.5 and Apache OpenOffice 3.4 with Java7 on Linux-64 and
Windows-32 platforms.

#25

Tom wrote

So, i made the page
https://wiki.documentfoundation.org/Faq/Java

I've cleaned up the FAQ/Java Wiki post on JRE 1.6.u35 and JRE 1.7u7 and Java
Access Bridge configuration.

My one continuing suggestion--have a single 32-bit JRE (1.6 or 1.7)
configured for use with LibreOffice, doesn't matter too much which
branch--but just one.

Stuart