Bug 54313

Summary: : LO should use a private java runtime, not a system wide one.
Product: LibreOffice Reporter: tortino <tortino>
Component: InstallationAssignee: Andras Timar <timar74>
Status: RESOLVED WONTFIX    
Severity: normal    
Priority: medium    
Version: 3.6.0.4 release   
Hardware: Other   
OS: All   
Whiteboard: BSA
Crash report or crash signature: Regression By:

Description tortino 2012-08-31 09:22:10 UTC
Problem description: 
I propose to add an option, during setup, to install Java Runtime as a private component into LibreOffice install directory, and _not_ as a system wide component.
There are many reasons to do this:
first of all I don't want java installed on my systems as a system wide component. I don't want the jre to be integrated into my browsers, because of security concerns (see the recent 0day flaw in java 7 not patched by oracle).
in addition in bugzilla there are some bugs about LO not working because of java: usually because it is installed the x64 java version instead of x86. sometimes because java is not found, for some reason, or because it was unistalled by the user, and then the same user is surprised that some features of LO doen't work anymore.
sometimes problems arise form an upgrade of the jre, done autmatically by java updater component. as an example moving from jre 6 to 7. or the user just want to install a new version. (see discussions like this: http://nabble.documentfoundation.org/Libreoffice-and-Java-td4003369.html).
Also when a new Java is installed it is not guarateed that it will work with LO (because of new bugs possibly introduced in the new version).
And LO is already bundling a private Python interpreter, so why not doing the same for java?
So I propose this:
-we choose a java version to be bundled with the LO setup.
-during development LO is tested using this version.
-during setup we default to just "unzip" this jre into the LO install directory, and use only that jre. 
- this private jre is "frozen", ie it is not updated automatically.
- if a new version is needed it will be distributed with an update of libre office.
- during setup we offer the option to use a different jre, instead of the private one bundled with LO.
- after setup is completed, if the user install another java system wide it is not automatically used by LO.
- the user still has the option, in the LO preferences, to use another JRE, like a system wide installed version.
- maybe LO, when configured to use another jre, should warn the user that it isn't the "official" tested version.
- if the entire jre is too big to be bundled, LO could bundle openjdk instead of the official oracle binary, so maybe it will be possible to just ship a subset of all the files, just the ones implementing the features used by LO (corba is it necessary?).

Platform (if different from the browser): 
possibily all platforms, but surely on windows.              
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0
Comment 1 Urmas 2012-08-31 20:10:29 UTC
I have a better proposal: to remove Java from LO completely. That festering unmaintainable security hole has no place on user machines.
Comment 2 tortino 2012-09-01 08:20:41 UTC
(In reply to comment #1)
> I have a better proposal: to remove Java from LO completely. That festering
> unmaintainable security hole has no place on user machines.

well, I agree to remove java, but there is a lot of code to be converted, it won't happen soon (if at all). try searching for "java" in bugzilla, it seems no easy to remove it (mainly because of base and hsqldb).
so the private jre can help fixing many problems in a short time.
Comment 3 Andras Timar 2012-09-04 13:14:41 UTC
We do not want to bundle JRE into LibreOffice Windows installer. 
1) size
2) uncertainty around the license
Comment 4 tortino 2012-09-10 15:09:21 UTC
well, about size I cannot comment, hovever license is permitted by oracle, and there is also a list of files in the jdk that you can remove, if you don't need it. see here:
http://www.oracle.com/technetwork/java/javase/terms/readme/index.html
As an example for JRE 7:

To run your application, a user needs the Java SE Runtime Environment,
which is freely available from Oracle. Or, you can redistribute the
Java SE Runtime Environment for free with your application, according
to the terms of the Oracle Binary Code License Agreement for the Java 
SE Platform Products.
<...cut...>
The files that make up the Java SE Runtime Environment are divided into
two categories: required and optional.  Optional files may be excluded
from redistributions of the Java SE Runtime Environment at the
vendor's discretion.

so the license is not a problem. the only problem is size, but this feature can resolve quite some problems of compatibility with users' systems (and don't forget ease of use: just install LO, don't bother woth Java). So maybe it's worth reevaluating.

Thanks.